Blind kiezen maakt testen goedkoper

De oorzaak van toenemende testkosten is algemeen bekend: bedrijven zijn in toenemende mate afhankelijk van de in gebruik zijnde informatiesystemen. Falende geautomatiseerde systemen vormen derhalve een groot risico voor de continuïteit van de bedrijfsvoering. Om dit risico te kunnen inschatten en waar mogelijk te verkleinen worden tests uitgevoerd op nieuwe of aangepaste informatiesystemen. Maar met de toenemende afhankelijkheid die zij hebben, voelen bedrijven zich genoodzaakt deze systemen steeds intensiever en uitgebreider te testen. Met andere woorden: er worden steeds hogere eisen gesteld aan de kwaliteit van de gebruikte testgevallen. In sommige gevallen poogt men deze kwaliteitsverhoging te bereiken door simpelweg steeds meer testgevallen te gebruiken, in het geval van releasematig onderhoud bijvoorbeeld door bij elke release een volledige regressietest uit te voeren. Een andere benadering bestaat eruit om steeds verfijndere methoden en technieken toe te passen teneinde de ‘juiste’ testgevallen te kunnen identificeren. Onder juiste testgevallen worden dan testgevallen verstaan waarmee eventuele bedrijfsrisico’s beter kunnen worden ingeschat en zo mogelijk kunnen worden geminimaliseerd. Testsets worden in deze benadering dus steeds fijnmaziger van opzet. Het is echter de vraag of deze strategie van steeds grotere of fijnmazigere testsets opstellen het gewenste effect sorteert. Wellicht is het een goed idee om een geheel andere benadering te kiezen en ons af te vragen of er niet veel meer te winnen valt bij het ‘op goed geluk’ uitkiezen van testgevallen en het toeval (of de statistiek) zijn werk te laten doen. Arbeidsintensief Hoewel er verschillende manieren zijn waarop een testtraject kan worden ingericht, hebben veel van deze manieren een aantal gemeenschappelijke kenmerken. Zo is het goed gebruik om voor een testtraject een testplan op te stellen; een plan van aanpak, vergelijkbaar met een projectplan. In het testplan worden zaken behandeld als op te leveren producten, uit te voeren activiteiten, uitgangspunten en randvoorwaarden, en een planning. Verder wordt veel aandacht besteed aan het opstellen van testgevallen en het vastleggen hiervan in zogenaamde testontwerpen. Dit laatste vooral met als doel de uit te voeren tests herhaalbaar, controleerbaar en overdraagbaar te maken. Alvorens te kunnen overgaan tot het maken van een testontwerp is het overigens van belang eerst antwoord te hebben op de vraag: hoeveel testgevallen moeten er worden gemaakt? En niet minder belangrijk: welke testgevallen moeten er worden gemaakt? Met andere woorden: wat moeten we wel testen en wat niet? Het is immers evident dat het bij een voldoende groot informatiesysteem onmogelijk is om alle mogelijke testgevallen uit te voeren. De tijd en het budget hiervoor ontbreken gewoonweg, mede gezien de hierboven geschetste ontwikkelingen rond intensiteit en doorloop van testtrajecten. Hierdoor ziet elke testontwerper zich genoodzaakt een keuze te maken uit de vele mogelijke testgevallen die te bedenken zijn. De afgelopen jaren is veel tijd en energie gestoken in het vaststellen van werkwijzen en criteria die zouden moeten leiden tot een verantwoorde keuze van testgevallen. Een veel gebruikte methode om te kunnen vaststellen hoe de aard en spreiding van de uit te voeren testgevallen moet zijn, is het uitvoeren van een risicoanalyse. Hierbij wordt voor de diverse onderscheiden systeemcomponenten een inschatting gemaakt van het (bedrijfs)risico dat wordt gelopen wanneer de betreffende component niet of niet goed zou functioneren. Vervolgens wordt de testinspanning (het aantal op te stellen en uit te voeren testgevallen per systeemcomponent) verdeeld op basis van de uitkomst van deze risicoanalyse, veelal volgens het principe: hoe groter het risico, hoe meer testgevallen er nodig zijn. Het vervolgens daadwerkelijk opstellen van de testgevallen gebeurt over het algemeen met gebruikmaking van testspecificatietechnieken. Dat zijn technieken om op gestructureerde wijze testgevallen af te leiden uit een document. Voorbeelden van testspecificatietechnieken zijn beslissingstabellen, algoritmetesten en dataflowtesten. In de meeste gevallen komt het toepassen van deze technieken neer op het vertalen van de uitgangsdocumentatie (ofwel de testbasis) naar een meer gestructureerde vorm (algoritme, beslissingstabel) waaruit de mogelijke testgevallen eenvoudig(er) zijn af te lezen. Vervolgens worden de testgevallen uitgeschreven in een testontwerp. De vorm waarin dit gebeurt volgt in veel gevallen de klassieke driedeling van ‘uitgangssituatie’ (wat moet je hebben om de test uit te kunnen voeren?), de ‘actie’ (wat moet je doen?) en de ‘uitvoervoorspelling’ (wat is het verwachte resultaat?). De voordelen van bovengeschetste werkwijze zijn evident: het zwaartepunt van de test ligt daar waar de meeste risico’s worden gelopen. En de te gebruiken testgevallen worden op dusdanige manier opgesteld dat controleerbaar is hoe de testontwerper aan zijn testgevallen is gekomen. Verder is de test door het vastleggen van de testgevallen in een testontwerp herhaalbaar, onderhoudbaar en overdraagbaar gemaakt. Er kleeft aan deze methode echter ook een groot nadeel; zij is erg arbeidsintensief. Vooral de vertaling van de uitgangsdocumentatie naar een meer gestructureerde vorm en het vervolgens uitschrijven van de testgevallen kost in het algemeen erg veel tijd. Bij een project van enige omvang is het niet ongebruikelijk dat een aantal testontwerpers tenminste enkele weken, soms zelfs maanden, bezig is met het opstellen van de testontwerpen. Het gevolg van deze werkwijze is dan ook dat testactiviteiten regelmatig zo’n 40 tot 50 procent van het totale projectbudget opsouperen. Hier komt uiteraard bij dat deze werkwijze een zware wissel trekt op de totale doorloop van een project. Steekproef Er is echter een alternatief voorhanden. Het testen van een geautomatiseerd systeem is namelijk op te vatten als het nemen van een steekproef uit de populatie van het totaal aantal mogelijke testgevallen. Met als doel het afleiden van de kwaliteit van het gehele systeem op basis van de resultaten van de steekproef. Maar als testen niets meer of minder is dan het nemen van een steekproef, moeten ook de regels die gelden voor het nemen van een steekproef worden geëerbiedigd. En door consequent deze regels te volgen kan vervolgens enorm veel tijd (en geld) worden bespaard. Testgevallen dienen in dat geval namelijk volkomen willekeurig te worden gekozen. Het maken van een testontwerp is dan ook weinig zinvol, en zelfs af te raden. Bij het maken van een testontwerp komen de testgevallen immers verre van willekeurig tot stand; de testontwerper bepaalt, al dan niet op basis van vastgelegde criteria, welke testgevallen wel en welke niet opgenomen zullen worden in de testset. Dit soort menselijke keuzes dienen bij het nemen van een steekproef nu juist zo veel mogelijk vermeden te worden. In het ideale geval zouden de testgevallen zelfs door een ‘random generator’ moeten worden vastgesteld. Met deze methode is een enorme tijdwinst te boeken op het testtraject en derhalve op de totale projectdoorloop. En zonder dat wordt ingeleverd op de kwaliteit van de uitgevoerde test. Integendeel: er wordt gewerkt volgens de regels die gelden voor het samenstellen van een goede steekproef, en de resultaten zijn dienovereenkomstig betrouwbaarder. Een bijkomend voordeel van de statistische benadering van testen is dat het minimum aantal testgevallen dat nodig is voor het bereiken van de gewenste nauwkeurigheid (van de kwaliteitsvoorspelling) op eenvoudige manier eenduidig kan worden vastgesteld. Hierdoor vervalt voor een groot deel de noodzaak tot het uitvoeren van een diepgaande risicoanalyse, die zoals we hebben gezien immers voornamelijk tot doel heeft om vast te stellen hoeveel testgevallen er per systeemonderdeel moeten worden uitgevoerd. Ook dit betekent een flinke besparing op de totaal benodigde tijd die voor een testtraject nodig is. Alternatief Met andere woorden, gezien het steeds grotere beslag dat testen legt op het budget en de doorloop van automatiseringsprojecten zouden we ons wellicht moeten afvragen of we met het streven naar steeds betere en uitgebreidere testsets wel op de goede weg zijn. Is in de huidige situatie het te bereiken (test)doel nog wel in balans met de daarmee gepaard gaande kosten? En is er misschien een alternatief, dat minder arbeidsintensief is, maar toch een betrouwbaar beeld oplevert van de kwaliteit van het geteste product? Zoals hierboven geschetst zou een alternatief kunnen zijn het uitvoeren van een test op een informatiesysteem op te vatten als het nemen van een steekproef, waarbij dan natuurlijk wel de regels die gelden voor het nemen van zo’n steekproef consequent gevolgd moeten worden. Dit kan een positief effect hebben op de kosten en de doorloop van een testtraject, en daarmee op het gehele project, zonder dat noemenswaardige afbreuk wordt gedaan aan de kwaliteit van de uitgevoerde test. Alleen al vanwege dit laatste zou het de moeite waard kunnen zijn eens nader te kijken naar ‘testen als statistische activiteit’. AUTEUR: Rob Henzen Rob Henzen werkt als (test)consultant bij Refis system reliability engineering te Bilthoven (www.refis.nl). Hij houdt zich vooral bezig met betrouwbaarheidsanalyses van informatiesystemen, het opzetten en begeleiden van testtrajecten en het uitvoeren van audits op test- en ontwikkelingstrajecten.