Steeds meer systemen worden ontwikkeld met behulp van ‘rapid application development’, of daarvan afgeleide methodes. Kan en moet gestructureerd testen, zoals dat een integraal onderdeel is van de meer conventionele methoden, onverkort worden toegepast bij rad? Een medewerker van KZA Kwaliteitszorg doet verslag van zijn (dynamische) ervaringen als tester.
De systeemontwikkelingsmethodieken zijn aan veranderingen onderhevig. Aanvankelijk leken de zogenaamde watervalmethoden, met sdm (systems development method) als bekendste, de wereld van de systeemontwikkeling te hebben veroverd. Inmiddels is duidelijk geworden dat deze methodieken zo hun nadelen hebben. De lange doorlooptijd leidde tot hoge kosten, terwijl de omgeving van de klant in de tussentijd kon wijzigen. Hierdoor leverde het systeem soms niet de oplossing waar de klant op het moment van oplevering op zat te wachten. Nog vaker kwam het voor dat automatiseerders en gebruikers een andere taal spraken. De communicatiekloof bleek onoverbrugbaar. Allereerst werd toevlucht gezocht in het structureren van het communicatieproces. Er werden stapels beschrijvingen gemaakt die tot in detail moesten aangeven wat het systeem moest doen. De gebruiker moest zijn handtekening in bloed er onder zetten, waarna de automatiseerder de papieren meenam en na lange tijd terugkwam met de mededeling dat het systeem klaar was. Vaak klonk vervolgens de kreet: ‘Ja, maar dat was de bedoeling niet!’. Dit gevaar bleef op de loer liggen, alle maatregelen om het functionele ontwerp (fo) te verbeteren ten spijt.
Uit de wens om deze nadelen te ondervangen is rapid application development geboren. Dat moest in ieder geval leiden tot systemen die niet via allerlei reparatieslagen hersteld hoeven te worden.
Omdat gebruiker en automatiseerder elkaars taal niet verstaan, moeten zij meer met elkaar communiceren. Een hoge gebruikersparticipatie is dus een kritische succesfactor voor een rad-ontwikkeltraject.
Daarnaast is duidelijk geworden dat de gebruiker vaak niet in één keer kan aangeven wat hij wil. Ook bij hem moet het besef groeien hoe het systeem eruit moet gaan zien. Het systeem moet dus meerdere iteratieslagen doormaken.
Ook is het van belang dat de eerste resultaten snel zichtbaar worden, omdat de tijd tussen de opdrachtverstrekking en de eerste concrete resultaten vaak te lang is. Het heroverwegen van keuzes kan dan eerder in het traject plaatsvinden. Bij sdm (systems development methodology) is het inzetten van meerdere teams de geijkte oplossing, maar dit leidt vaak tot afstemmingsproblemen. Hier schiet de technische vooruitgang te hulp; krachtige ontwikkeltools stellen de automatiseerder in staat snel met een werkend prototype te komen. Aldus ontstond rad, hier gedefinieerd als een systeemontwikkelingsmethode die gebaseerd is op hoge gebruikersparticipatie en iteratief ontwikkelen en die binnen korte tijd moet leiden tot een werkend product.
Fasering van testen
Is hiermee de kous af en de nieuwe methode volledig geaccepteerd? Nee. De afgelopen jaren hebben veel organisaties het gestructureerd testen van systemen – voordat ze in productie gaan – geaccepteerd als integraal onderdeel van de systeemontwikkeling. Tegenwoordig wordt bijna geen enkel systeem meer in productie genomen dat niet ‘door de mangel van het testen is gehaald’. De toenemende complexiteit en samenhang van systemen heeft het testen van een noodzakelijk kwaad tot een integraal onderdeel gemaakt.
De fasering van het gestructureerd testen is gebaseerd op de fasering van sdm. Zodra de bouwers met het functioneel ontwerp aan de haal gaan en het systeem gaan bouwen, beginnen de testers al met het opstellen van de strategie, wordt het functioneel ontwerp op testbaarheid gecontroleerd en begint het tijdrovende, maar kwaliteitsverhogende specificeren van testgevallen.
Bij rad kunnen we deze fasering van testen niet zomaar overnemen. Als de bouwers in actie komen is er nog geen functioneel ontwerp ; eigenlijk is dat pas af wanneer het hele systeem klaar is. Op het eerste gezicht lijken er twee oplossingen: later beginnen met testen of niet meer gestructureerd testen. Gezien de complexiteit en samenhang van de moderne systemen is de laatste optie eigenlijk niet reëel. Een primair proces afhankelijk maken van een niet gestructureerd getest systeem is voor veel bedrijven een te groot risico. Later beginnen met testen is geheel tegengesteld aan één van de doelen van rad: het verkorten van de doorlooptijd van de ontwikkeling. Het is toch zonde als de gewonnen tijd verloren gaat door een laat opgestart testtraject. Deze overweging was sterk voelbaar bij de projecten waar ik als tester in een rad-traject ervaring heb opgedaan. Je kon met veel verhalen bij de projectmanager aankomen, behalve met de boodschap dat het meer tijd moest gaan kosten. Op basis van deze beperkingen zijn wij op zoek gegaan naar een aanpak die tegemoet komt aan de wens om een goed oordeel over de kwaliteit van het programma te kunnen geven, in korte tijd en tegen lage kosten.
Dynamisch plannen
De fasering van het testen in een rad-traject ziet er op het eerste gezicht heel anders uit. Zoals vermeld is er geen functioneel ontwerp op het moment dat er wordt gestart met de eerste bouwactiviteiten. Over het algemeen is er wel een basis-ontwerp of iets dergelijks (voor één soort product zijn er vele aanduidingen). Hier ontstonden meestal al de eerste problemen voor ons. Bij waterval-trajecten wordt de teststrategie namelijk op het functioneel ontwerp gebaseerd; bij rad lukt dat niet. Echter, met het basisontwerp in de hand is er al een teststrategie in hoofdlijnen te maken. Omdat een strategie altijd in hoofdlijnen geformuleerd moet zijn – wat sommigen nog wel eens vergeten – moet dit eigenlijk voldoende zijn. Het invullen van de details volgt later. Dit heeft als bijkomend voordeel dat de ’trade-off’ tussen inspanning en diepgang dan wordt gemaakt op het moment dat de gebruiker het meeste besef heeft van de impact van zijn besluiten.
Het maken van de planning is in dit stadium moeilijker. Bij aanvang van het project is het namelijk niet duidelijk wat er precies gemaakt, en dus getest, gaat worden. Dit probleem openbaarde zich direct in het project: de projectmanager vroeg om een planning, maar die konden we niet geven. Aan het ontbreken van die planning moet echter niet te zwaar worden getild; het bouwteam weet immers ook niet precies wat het wanneer gaat doen. Tijdens het proces wordt meer duidelijk over het product en de werkzaamheden die moeten worden verricht. Dynamisch plannen en flexibiliteit – beide wekken allergische reacties op bij de aanhangers van watervaltrajecten – zijn een oplossing voor het geschetste probleem.
In ons project hielden wij de werklast continu in de gaten. Liep die op, dan gingen we over tot het stellen van prioriteiten (een mooi woord voor wat je wel en niet gaat doen); als dat geen uitkomst bood werd er een nieuwe tester aangesteld. Uiteindelijk kwamen we op deze manier uit op 3/4 tester per bouwer.
‘Intake’
De volgende activiteit die bij het gestructureerd testen wordt uitgevoerd, is de ‘intake’ van het functioneel ontwerp. Voordat begonnen wordt met het specificeren van testgevallen moet de kwaliteit van het uitgangsmateriaal worden vastgesteld. Nadeel van de rad-werkwijze is dat ontwerpbeslissingen meteen worden geëffectueerd en de vastlegging ervan nogal eens achterwege blijft. Er zijn nog steeds mensen die zeggen dat het bewaren van deze beslissingen overbodige inspanning is. Die zijn toch immers direct geëffectueerd in het pakket en geheel conform de wens van de gebruiker. Toegegeven, deze werkwijze komt op korte termijn de ‘r’ van rad ten goede (of zoals een collega van mij zegt: je moet toch ergens op bezuinigen); op lange termijn ligt dat anders. Als niet vastligt waarom bepaalde keuzes zijn gemaakt, wordt het ook moeilijk later de impact van de wijziging te overzien. Hierdoor kunnen er ongewenste inconsistenties in de pakketten sluipen. Voor onderhoud zijn goede specificaties een vereiste! Daarnaast moet de test gebaseerd worden op meer dan een interpretatie van de tester; ook hiervoor zijn goede functionele specificaties een vereiste.
De gedachte dat er bij aanvang geen functioneel ontwerp is en dat er dus geen ‘intake’ hoeft plaats te vinden, is te kort door de bocht. Bij rad moeten de testgevallen immers ook gebaseerd worden op de documentatie, dus moet ook hier worden vastgesteld of die van voldoende kwaliteit is. Het functioneel ontwerp komt echter geleidelijk, gelijk met de software, tot stand. De ‘intake’ vind dus niet één keer plaats maar veel vaker, eigenlijk na iedere iteratie en voor ieder systeemonderdeel. Een goede checklist waarmee snel en eenduidig is vast te stellen of de opgeleverde delen van het functioneel ontwerp voldoende zijn om een goede test op te baseren, is dus erg belangrijk.
Deze ‘intake’ bleek goed te structureren. De structuur is in het proces gekomen doordat de functionele ontwerpers van ons projectteam doorkregen welke testers kritisch waren bij de ‘intake’ en welke niet. De niet zo kritische tester kreeg de meeste functioneel ontwerpen, zodat de ontwerper het functioneel ontwerp niet zo snel terug kreeg. Toen wij (het testteam) dit door hadden, maakten we een goede, uitgebreide checklist met alle zaken die we wilden controleren, en gingen we met twee man een ‘intake’ doen. Een onbedoelde, maar zeer prettige situatie ontstond toen de ontwerpers de checklist in hun handen kregen. Om te voorkomen dat ze veel functioneel-ontwerpbevindingen kregen, gingen de functioneel ontwerpers de checklist zelf toepassen. Dit leverde ons veel tijd op! (Dit hebben we overigens nooit verteld aan de functioneel ontwerpers).
Specificeren
De werkzaamheden met betrekking tot het specificeren van testgevallen – de derde fase van het gestructureerd testen – veranderen in principe niet. Er bestaan echter wel essentiële verschillen met watervaltrajecten. Allereerst worden verschillende delen meerdere keren bewerkt. Na het verschijnen van de eerste versie geeft de gebruiker zijn wensen te kennen en wordt deze aangepast.
Moet de tester nu wachten tot het product uitgeïtereerd is? Nee, dan begint het specificeren pas als het systeem klaar is, en dat is te laat. Zodra de eerste versie van het systeem het daglicht heeft gezien, moet de tester de eerste versie van zijn specificaties maken. Door meteen ook de eerste versie van de programmatuur te testen, kunnen bevindingen bij de tweede iteratie worden meegenomen. Hier moeten de specificaties dus worden aangepast; dit stelt hoge eisen aan de toegankelijkheid van de specificaties! Bij rad-trajecten is het dus nog belangrijker om normen en standaarden te hebben voor testspecificaties. Op dit punt zijn wij onszelf als testers nogal eens tegengekomen. In het begin legden we niet alles even goed vast. Het gevolg was dat we bij het verschijnen van de tweede versie van de programmatuur de testspecificaties van de eerste test niet echt konden gebruiken. Daardoor moesten we opnieuw specificaties opstellen. Afgezien van de tijd (en dus geld) die het kostte, was het ook gewoon niet leuk. Daarom hebben we vrij snel standaarden en normen opgesteld. Dit vergrootte de aanpasbaarheid en dus de herbruikbaarheid van de testspecificaties enorm!
‘Time-box’
Regelmatig wordt de mening geuit dat het goed is om voor het testen een ’time-box’ te gebruiken: een beperkte hoeveelheid tijd. Is de tijd om, dan wordt bezuinigd op de functionaliteit. Bij aanvang van het project gebeurde dit ook. Er deed zich echter een groot probleem voor. De hoeveelheid functionaliteit staat voor het testteam namelijk vast; deze wordt opgeleverd door het bouwteam. De enige overgebleven bezuinigingsmogelijkheden zijn de diepgang en de kwaliteit van het testen. In feite wordt er dan geknaagd aan (het inzicht in) de kwaliteit van het systeem en worden de risico’s van in productiename bepaald door de beschikbare tijd. Het hangt af van het belang van het systeem en de risico-inschatting door het management, dat ermee gaat werken, of dit acceptabel is. Na de eerste testtime-box gaven we aan dat slechts een deel van de programmatuur was getest. Het testen in time-boxen werd dientengevolge losgelaten. Voortaan werd weer gestuurd op een hoge dekkingsgraad van de test en moesten alle bevindingen die een hoge prioriteit hadden, opgelost zijn.
Het is eventueel wel mogelijk om de eerste testiteraties in timeboxen uit te voeren en afhankelijk van de opgedane ervaringen te besluiten of men dat later in het traject ook wil. Als de relatie foutinjectie-foutdetectie (de tijdspanne tussen het moment dat een stuk software met een onvolkomenheid wordt opgeleverd en de onvolkomenheid wordt geconstateerd) te groot wordt, is dit een indicatie dat in de geboden timebox met onvoldoende kwaliteit en diepgang getest is.
Inzet gebruikers
Een belangrijke vraag bij rad en testen is of de gebruiker niet kan meewerken bij het specificeren van testgevallen. Vaak heeft hij niet voldoende om handen als hij alleen maar aanwezig is om de bouwer en de ontwerper te voeden met informatie. Naast vraagbaak en oplosser mag hij niet een sta in de weg worden. Opdat hij niet alleen commentaar levert maar ook vaststelt dat de juiste oplossing daar is, is enige testverantwoordelijkheid een welkome aanvulling op zijn takenpakket. En wie kan er beter vaststellen of de wensen en eisen goed zijn uitgevoerd dan de gebruiker zelf? Vooral op het gebied van de gebruikersinterface kan hij de nodige test- en toetswerkzaamheden verrichten. De voordelen hiervan zijn duidelijk; de test kan leiden tot input voor de volgende iteratie, en de gebruiker wordt geconfronteerd met de impact van zijn wensen. Hij heeft nu eenmaal meer feeling met de praktijk waarbinnen het pakket gebruikt moet gaan worden.
Is het gevolg hiervan dat de professionele en onafhankelijke tester helemaal buiten de deur gehouden kan worden? Nee, er is zeker nog het nodige werk voor de professionele tester.
Om te beginnen zijn er vraagtekens te zetten bij de gestructureerdheid van de aanpak van de gebruiker. Voor die delen waar de gebruiker het best in is, de gebruikersinterface en de in- en output, kan zijn inzet nog acceptabel zijn, al kleven hier natuurlijk risico’s aan. Indien de gebruiker niet geschoold is als tester, zal hij in het geval van een scherm waarschijnlijk alleen kijken of dat aan zijn wensen voldoet en wellicht één of enkele gevallen proberen. Als zo’n scherm gemaakt is met een goed tool, is dit nog een acceptabele manier van werken. Zodra het gaat om het testen van de functionaliteit, ligt het anders. Het analyseren van functiebeschrijvingen en het specificeren van testgevallen, zodanig dat met een minimum aantal testgevallen een zo hoog mogelijke dekking wordt bereikt, blijft het domein van de professionele tester. Zeker indien het maken van reproduceerbare testen gewenst is – en dat is toch zeker bij rad het geval – is het gebruik van testtechnieken essentieel.
Testtools
Bij rad worden dezelfde testtechnieken gebruikt als bij watervaltrajecten. Er gelden immers dezelfde eisen, zodat er met gelijke diepgang moet worden getest. Natuurlijk verandert de gebruikersinput het bouwproces, maar de gebruiker test niet of het systeem ook werkt zoals hij heeft aangegeven; dit blijft het werk van de tester.
Het itererende karakter van rad leidt tot een herhaald uitvoeren van (licht gewijzigde) testgevallen. Ook hier is het zorg dat de specificaties en scripts helder en éénduidig zijn. Hierbij kan het wenselijk zijn om vulscripts elektronisch beschikbaar te hebben. Verder is het hier van belang om ze toegankelijk en gestructureerd beschikbaar te hebben. Bij een datamodelwijziging (ook dat gebeurt!) moet de hele boel namelijk weer aangepast worden. Het herhaald uitvoeren van scripts en het vullen van databases roept heel hard om testtools! Eigenlijk is dat niet meer dan eerlijk: waar bouwers in rad-trajecten worden bijgestaan door allerhande ontwikkeltools om hun werk sneller (en leuker) te maken, mogen testers dat eigenlijk ook wel.
De laatste fase van het gestructureerd testen is de conservering. Hoewel die ook bij rad aan het eind moet plaatsvinden, is het eigenlijk belangrijker dat de testscripts continu geconserveerd worden. Omdat scripts vaak meerdere keren worden uitgevoerd, moeten ze dus ook altijd up-to-date worden gebracht.
‘Joint application design’
De fasen van het gestructureerd testen zijn terug te vinden bij het testen in een rad-traject, maar worden meerdere keren uitgevoerd. Dat l�jkt niet alleen logisch, maar dat is het ook! Rad is eigenlijk een opeenvolging van kleine ontwikkelcycli. Iedere cyclus begint met een ontwerp-deel; dit heet joint application design. Vervolgens vindt in die cyclus een deel bouw plaats. Aan het eind van de cyclus is er dan een werkend prototype dat het uitgangspunt vormt voor de volgende cyclus. Zoals het gestructureerd testen tijdens en vlak na het totale proces plaatsvindt bij de watervalmethode, zo vinden dezelfde activiteiten van het gestructureerd testen tijdens en na iedere cyclus plaats.
Uiteindelijk had ik als tester in een rad-traject het gevoel in essentie niet anders bezig te zijn geweest. De input bleef een functionele beschrijving, de output een stapel bevindingen die opgelost werden. Wat het rad-traject echt anders maakte, waren de randverschijnselen zoals de inbreng van de gebruikers, het werken met timeboxen, de vele iteraties en vooral de hoge dynamiek. Vandaag kon het linksaf zijn, morgen kon het ‘door gewijzigde inzichten’ rechtsaf zijn. Het beheersen van die randverschijnselen was de uitdaging. Een uitdaging die vooral een aanslag deed op je flexibiliteit: niets was immers zeker of stond vast.
Drs. H.J.J. Cannegieter, accountmanager bij KZA Kwaliteitszorg