Ontwikkelen van niet beheerbare testware is te beschouwen als kapitaalvernietiging. Om de beheerbaarheid, herhaalbaarheid en herbruikbaarheid van de testware te verbeteren werd een model ontwikkeld. Hiermee is het ondermeer mogelijk om impactanalyses op de testware uit te voeren, aldus een medewerker van Maintain Software Management.
Steeds meer organisaties nemen het testen van systemen serieus. Een belangrijke rol hierbij speelt het toenemend kwaliteitsbewustzijn bij zowel de klant als de producent.
Hoewel het belang is toegenomen, betekent dit niet dat testers voorop lopen als het gaat om methodische ondersteuning. Zowel het denken over als het feitelijk bieden van ondersteuning is nog niet zo ver ontwikkeld als bijvoorbeeld het ontwerpen en bouwen van systemen. Dit betekent niet zozeer dat er geen gestructureerde werkwijzen zouden bestaan, maar veel meer dat deze zich in een ‘vroeger’ stadium van ontwikkeling bevinden.
In de optimale situatie testen we niet alleen het op te leveren nieuwe systeem maar ook aangepaste systemen of onderdelen en relaties tussen niet-gewijzigde en gewijzigde systemen; in het laatste geval maken we gebruik van een regressietest. Een dergelijke aanpak heeft tot gevolg dat de eisen die aan de systeemontwikkelaars worden gesteld om de opgeleverde producten beheerbaar en onderhoudbaar te laten zijn, op een vergelijkbare manier aan de testers moeten worden gesteld, om de producten die zij opleveren beheerbaar en onderhoudbaar te maken.
Helaas komt het nog steeds voor dat men na acceptatie het testen als afgerond beschouwt en dat de testproducten vervolgens in een ‘zwart gat’ verdwijnen. Dit hoeft niet direct in te houden dat ze worden weggegooid; integendeel, ze komen in een kast of worden ergens op schijf gearchiveerd.
In de praktijk blijkt vervolgens dat men bij aanpassing van het systeem geneigd is de wijzigingen ‘even gauw’ te testen, omdat dat ‘makkelijker’ is dan terug te grijpen op de bestaande testware.
Het gevolg van deze aanpak is dat de testers de eerder bewaarde testware niet meer aanpassen, waardoor deze veroudert en feitelijk kan worden weggegooid.
De overeenkomst met de praktijk zoals die vroeger bij systeemontwikkeling plaatsvond, is groot genoeg om de daar opgedane ervaring toe te passen op het testproces.
De eerste les is dat de testers de producten zodanig documenteren dat deze ook later bruikbaar zijn. Voorts is het van belang om bij het opzetten van de documentatie standaarden te gebruiken die voorschrijven welke producten er gemaakt moeten worden, hoe dat moet gebeuren en aan welke eisen deze moeten voldoen.
Verder moeten we het testproces faseren. Het is immers veel te complex om in één keer te behappen, en de (tussen)producten die we gebruiken voor het ontwikkelen van de testware komen zelf ook gefaseerd ter beschikking.
Deze lessen zijn gebruikt bij het ontwikkelen van een model dat dient om een gestructureerde werkwijze te ondersteunen op een zodanige manier dat beheer en herbruikbaarheid van de testware goed mogelijk zijn.
Werkwijze
In het navolgende gaan we uit van een traditionele (lineaire) ontwikkelmethode. Voor de uitwerking van een cyclische aanpak is voornamelijk een andere fasering nodig; de producten verschillen in mindere mate.
Bij aanvang van de ontwikkeling van een systeem formuleert de opdrachtgever een aantal acceptatiecriteria. De definitiestudie bevat de doelstelling van het te ontwikkelen systeem en de algemene eisen waaraan het moet voldoen; deze dienen als basis voor de acceptatietest.
Het functioneel ontwerp is de basis voor de systeemtest. De testers gebruiken dit bij het maken van een logisch testontwerp waarin logische testgevallen zijn opgenomen.
In het technisch ontwerp wordt het ‘wat’ van het functioneel ontwerp omgezet in het ‘hoe’. Op basis van deze transformatie kunnen de logische testgevallen worden aangevuld met technische details; dit noemen we het fysiek testontwerp. Het technisch ontwerp levert tevens de basis voor de integratietest.
In de realisatiefase bouwen de ontwikkelaars het systeem aan de hand van de technische specificaties.
Het uitvoeren van de tests geschiedt in omgekeerde volgorde. Eerst testen de bouwers hun eigen programmatuur, daarna volgt de integratietest. Vervolgens draagt de ontwikkelgroep het systeem over aan de functionele testgroep.
De laatste stap is de acceptatietest. Deze bestaat veelal uit twee delen: een test waarbij de organisatie onderzoekt of het opgeleverde systeem voldoet aan de doelstelling en één waarbij de exploitant onderzoekt of het systeem in exploitatie kan worden genomen op de beschikbare infrastructuur.
Deze werkwijze, bekend onder de naam V-model (figuur 1), heeft onder andere de volgende voordelen.
Het opstellen van de test dient tevens als toets van het ontwerp (dit leidt tot foutpreventie en daarmee tot beperking van de herstelkosten in een later stadium). Verder is er een scheiding van verantwoordelijkheden (er wordt namelijk ook namens of door de opdrachtgever getest). En ten slotte wordt de onvermijdelijke druk op het uitvoeren van de tests gedeeltelijk verlicht doordat de voorbereiding al voor een groot deel is afgerond.
 |
| Figuur 1. Schema van het V-model. Het uitvoeren van de tests geschiedt in omgekeerde volgorde als de ontwikkeling van het systeem. |
Beheerbaarheid
Met de aanzet voor een min of meer formele testmethode hebben we nog geen zekerheid dat er herhaalbare, beheerbare en herbruikbare testware wordt gemaakt. Om dit te bereiken zullen we eisen moeten stellen aan de manier waarop de producten toegankelijk worden gemaakt en informatie over de producten verkrijgbaar is.
Ook hier is een parallel met systeemontwikkeling zichtbaar: in eerste instantie werd het ontwerp (alleen) op papier gezet, later met behulp van een tekstverwerker elektronisch vastgelegd en vervolgens met hulpmiddelen (case) gerealiseerd.
Op dit moment zijn de meeste organisaties zo ver dat ze de testproducten in ieder geval elektronisch (tekstverwerker, spreadsheet) beschikbaar hebben. Beheer en onderhoud geschiedt dan met de beschikbare hulpmiddelen (de zoek- en vervang-functie).
In verband met beheer is het noodzakelijk inzicht te hebben in enerzijds de verschillende testproducten en hun onderlinge samenhang en anderzijds de relatie met de producten van systeemontwikkeling.
Het ‘waarom’ hiervan mag duidelijk zijn: als we niet weten op welke wijze de verschillende testproducten samenhangen, kunnen we niet voorspellen wat de gevolgen zijn van wijzigingen. En als we niet weten wat de relatie is tussen de testproducten en de systeemontwikkelingsproducten, dan weten we ook niet welke testproducten voor aanpassing in aanmerking komen op het moment dat er wijzigingen in het systeem worden doorgevoerd.
Om de beheerbaarheid, herhaalbaarheid en herbruikbaarheid van de testware te verbeteren hebben we een model ontwikkeld. Dit model dient als basis voor het geautomatiseerde ondersteunen van de ontwikkeling en het beheer van testware.
Omdat het leeuwendeel van de te beheren testware betrekking heeft op de dynamische testen (testen met het ‘draaiende’ systeem), ligt hierop de nadruk. Hieronder volgt een beschrijving van het model op basis van de benodigde (test)objecten, waarbij in eerste instantie het voortraject van het testproces wordt belicht.
De objecten
De acceptatiecriteria en kwaliteitseisen die de betrokkenen aan het systeem stellen, bepalen voor een groot deel de ‘vragen’ waarop de testers een antwoord – kwantitatief of kwalitatief – moeten geven.
Een aantal van de criteria en eisen zal speciaal voor dit systeem zijn opgesteld, andere zullen ‘standaard’ of zelfs impliciet zijn. Aan het begin van de testvoorbereiding werken de testers de criteria en eisen voor dit systeem uit, resulterend in de ’testdoelen’.
Een testdoel beschrijft wat er wordt gemeten en geeft een antwoord op de vraag waarom deze test wordt uitgevoerd.
Van een testdoel wordt vastgelegd: de omschrijving; in welke meeteenheid het resultaat wordt uitgedrukt, en aan welke norm het systeem moet voldoen.
Aan elk systeem ligt een aantal ontwerpen ten grondslag waaraan de verschillende tests worden ontleend: de ’testbasis’. Het soort ontwerp is niet van groot belang; elk ontwerp waarin een deel van het systeem staat beschreven voldoet. De testbasis benoemt slechts; het omvat niet de documenten zelf.
Van de testbasis wordt vastgelegd: om welk deel van het systeem het gaat; de soort beschrijving (functioneel ontwerp, styleguide, enz.), en de identificatie (versie, datum, enz.)
We testen altijd ‘iets’. Dat kan een programma zijn, maar ook de opgeleverde handleiding en werkinstructies; we spreken over het ’testobject’. Ook voor het testobject geldt dat het slechts gaat om het benoemen ervan; er zijn daarom ook geen ingewikkelde relaties tussen testbasis en testobject voorzien.
Van het testobject wordt vastgelegd: de identificatie van het testobject, en het soort testobject (uitvoerbaar, ao-beschrijving, enz.)
Aan de hand van de testdoelen en de testbasis beschrijven de testers situaties waarmee ze het systeem testen. Elk van deze situaties dekt een (uniek) deel van het systeem af. Het ’testgeval’ beschrijft zo’n unieke testsituatie.
Elk testgeval heeft een resultaat; de ’testuitvoer’ beschrijft het verwachte resultaat van het systeem.
Om deze testuitvoer te verkrijgen, is het nodig het systeem iets aan te bieden waardoor het tot actie wordt gedwongen. De ’testinvoer’ beschrijft de handelingen of invoergegevens die hiervoor nodig zijn. Niet elke testinvoer leidt per definitie tot dezelfde uitvoer; de situatie waarin het systeem zich bevindt op het moment dat het de invoer krijgt aangeboden is hierbij van groot belang.
De ’testuitgangssituatie’ beschrijft de staat van het systeem op het moment dat de invoer wordt aangeboden.
Voor een voorbeeld van de testobjecten wordt verwezen naar het kader.
Relaties tussen objecten
Het (logisch) testgeval speelt een centrale rol in het model, van hieruit leggen we de relaties.
 |
| Figuur 2. Schema van het model en het uitgebreide model (inclusief stippellijntjes). Aan één testdoel kunnen meerdere testgevallen zijn gekoppeld. Van één testbasis zijn meerdere testgevallen af te leiden. Voor één testobject zijn meerder testgevallen te ontwikkelen. Elke testuitgangssituatie, testinvoer of testuitvoer kan voor één of meerdere testgevallen worden gebruikt. |
Het testgeval heeft in twee richtingen relaties (zie figuur 2); allereerst naar de objecten waaraan het is ontleend, te weten het testdoel, de testbasis en het testobject. Deze relaties zijn voor de beheerbaarheid van belang omdat hiermee de testgevallen zijn te vinden die wellicht voor onderhoud in aanmerking komen als er wijzigingen in het systeem plaatsvinden.
De tweede richting betreft de objecten waaruit het testgeval is samengesteld: de testinvoer, de testuitvoer en de test2uitgangssituatie.
Deze relaties zijn van belang voor de beheerbaarheid, omdat zij de interne samenhang van de testware beschrijven.
De combinatie van invoer, uitvoer en uitgangssituatie is uniek voor dit testgeval. Een testinvoer met een andere testuitgangssituatie zal (vaak) een andere testuitvoer tot gevolg hebben. Als de uitgangssituatie bijvoorbeeld verandert van ‘klant nog niet aanwezig’ in ‘klant al aanwezig’, dan zal de invoer leiden tot een andere uitvoer: ‘melding klant al aanwezig’.
Logisch en fysiek testgeval
Tot dusver zijn de ‘logische’ testgevallen beschreven, het ‘wat’ van het testen.
Nu nemen we het fysieke testgeval in het model op.
Voor het maken van een fysiek testgeval moeten de testers de onderdelen uitgangssituatie, invoer en uitvoer uitwerken, bijvoorbeeld door het invullen van waarden, het aangeven van de volgorde waarin stappen worden uitgevoerd, het specificeren van de toetsaanslagen en de wijze waarop het resultaat in de database wordt gecontroleerd.
Om dit in het model op te nemen moeten we het uitbreiden met een procedurele component voor de objecten testuitgangssituatie, testinvoer en testuitvoer (zie figuur 2, stippellijnen).
Het object testprocedure bevat de gegevens ’type’ en ‘uit te voeren procedure’.
Het ’type’ geeft aan bij welk object (uitgangssituatie, invoer of uitvoer) de testprocedure hoort. De ‘uit te voeren procedure’ kan van alles bevatten. In ieder geval staan hier de instructies die de tester moet uitvoeren, maar er kunnen ook ‘machine’-instructies in staan (denk aan batches of zelfs stukjes capture/playback-script.
Beperkingen en voordelen
Het model richt zich voornamelijk op het testen van de functionaliteit; testen die zijn gericht op de prestatie of de gebruikersvriendelijkheid zijn niet in te passen.
We hebben voor nadruk op het functionele aspect gekozen, omdat in de praktijk op dit gebied de meeste beheersmatige problemen optreden. Verder is het de vraag in hoeverre andere testen zich net zo eenduidig laten vastleggen; bij de test op gebruikersvriendelijkheid hanteren we een heel andere invalshoek.
Het hier gepresenteerde model is geïmplementeerd in een applicatie die draait op een MS-Windows (32-bit) platform.
Naast het model bevat deze applicatie functionaliteit voor het onderzoeken van de onderlinge relaties, het genereren van testscripts, het vastleggen van de resultaten van de testuitvoering en de registratie van bevindingen (incidenten).
Kapitaalvernietiging als gevolg van testware die niet kan worden beheerd is ons inziens niet nodig. Met het geschetste model is het weliswaar noodzakelijk dat de testers meer vastleggen, maar het inzicht in wat ze allemaal hebben ontwikkeld en hoe dat samenhangt maakt effectief beheer en onderhoud wel degelijk mogelijk. Bijvoorbeeld omdat ze nu impactanalyses op de testware kunnen uitvoeren.
Drs. Harm de Vries,
testconsultant bij Maintain Software Management BV te Zeist
Voorbeeld testobjecten
Eén van de eisen aan een systeem is dat er klanten mee te registreren zijn. Eén van de testen zal dus gericht zijn op het vaststellen van de juiste werking van deze functionaliteit.
Testdoel: vaststellen van de foutloze werking van het toevoegen van klanten (meeteenheid: percentage toevoegingen die conform specificaties zijn verlopen; norm: 100 procent);
Testbasis: functioneel ontwerp hoofdstuk xyz;
Testobject: programma xyz123;
Testgeval: invoeren van een nog niet bestaande klant;
Testinvoer: (opvoeren klant) achternaam, eerste voorletter, straat, huisnummer, postcode, woonplaats;
Testuitvoer: melding ‘klant is opgenomen in het systeem, rekeningnummer is 9999999999’, de klant is opvraagbaar in het systeem;
Testuitgangssituatie: de op te voeren klantgegevens komen niet voor in het systeem.
