Winst Exploratory Testen twijfelachtig

Altijd interessant wanneer er over nieuwe ontwikkelingen op het gebied van testen wordt gepubliceerd. Zo zette in oktober vorig jaar Rob Henzen duidelijke vraagtekens bij de klassieke teststrategieën. Deze strategieën met grotere en fijnmazigere testsets drukken steeds meer op projectbudgetten. Als alternatieve strategie pleitte hij voor het uitvoeren van testen aan de hand van steekproeven, een statistische benadering. Jaren geleden werden we ook al verblijd met de geboorte van ‘risk-based testing’. Erik van Veenendaal schenkt nu aandacht aan een nieuwe testtechniek: exploratory testen (ET). Hij beschouwt ET als complementaire techniek als een interessante toevoeging, die beslist aandacht verdient. Maar is dat daadwerkelijk zo? Veel aandacht Testen lijkt een onderwerp te zijn in het vakgebied der informatica, waar relatief veel aandacht naar uitgaat. Waarom? Het is natuurlijk uiteraard zo, dat testen tijd en geld kost. Het testen drukt enorm op een projectbudget en bepaalt mede de doorlooptijd van productontwikkeling. Een goede vuistregel is dat testen 20 tot 25 procent van zowel budget als doorlooptijd voor zijn rekening neemt. Dit betreft alleen de integratie- en systeemtest, dus niet de hieraan voorafgaande moduletesten. Doordat testen bovendien aan het einde van een project plaatsvindt, is er tevens druk om deze fase zo snel en goedkoop mogelijk te doorlopen. Het geld is bijna op en de klant staat te trappelen van ongeduld. Dit leidt tot het bedenken van steeds andere testtechnieken in het vakgebied. Verklaarbaar. Maar terecht? Het probleem in de software-industrie is dat er veel nieuwe technieken worden geïntroduceerd op basis van een buikgevoel. Elke nieuwe techniek heeft voordelen en nadelen, die echter meestal zeer intuïtief worden beredeneerd. De uitvinders van nieuwe technieken zien altijd de voordelen, mensen die meer behoudend zijn zien meestal de nadelen. Beiden zien zaken echter gekleurd. Al is een interessante stelling hier dat mensen met veel ervaring in het algemeen behoudender zijn. Het zou echter veel interessanter zijn om middels onderzoek (bijvoorbeeld praktijkstudies of experimenten) na te gaan in hoeverre de verwachte voor- en nadelen meetbaar waar zijn. Knellende vraag En toch blijft er dan een nog een knellende vraag over. Wat bieden dit soort nieuwe testtechnieken in de toekomst? Softwareproducten worden groter en complexer. Onze klassieke wijze van software ontwikkelen begint tegen grenzen aan te lopen. Klassieke wijze? Dat is het slecht omgaan met productspecificaties, het afleveren van krakkemikkige ontwerpen en het intuïtieve testen als verkapte vorm van verder ontwikkelen. Hoezo, is testen dan ontwikkelen? Er zijn twee grote misverstanden uit de weg te ruimen. In de eerste plaats wordt het hoge budget en de lange doorlooptijd van het testen meestal niet bepaald door de testuitvoering. Het is het opsporen en analyseren van gevonden fouten. In de tweede plaats kan met testen slechts de aanwezigheid van fouten worden aangetoond, nooit de afwezigheid. Het is zeker niet waar dat met testen de kwaliteit van een product kan worden verhoogd. Dit kan alleen maar door op basis van goede specificaties en ontwerp te werk te gaan. Dus het verhogen van de kwaliteit van software middels testen is niet anders dan het achteraf verhelpen van onvolkomenheden in specificaties en ontwerp op zeer dure wijze. Praktijkstudie Open deuren? Ja, maar daarom niet minder waar. Er zijn ook steeds meer technieken beschikbaar die het specificatie- en ontwerpproces zo ondersteunen, dat testen inderdaad teruggebracht kan worden tot normale proporties. Zo is recentelijk een interessante praktijkstudie, uitgevoerd binnen het Eindhovense Assembléon (voorheen Philips), gepubliceerd. Hierbij werden voor een kritisch subsysteem de informele specificaties omgezet in formele specificaties middels de Cleanroom Software Engineering Method. Het dynamische gedrag van de architectuur werd formeel beschreven middels een combinatie van twee andere formele technieken. Dit stelde het projectteam in staat om niet alleen eenderde van de code direct te genereren, maar ook alle testspecificaties. Bovendien stelde de aanpak het team in staat eenvoudig en snel specificatie- en ontwerpwijzigingen door te voeren. Geen aanpassing van allerlei testdocumentatie, eenvoudigweg opnieuw gegenereerd. De tijd voor integratie van het subsysteem met de rest van het systeem werd spectaculair gereduceerd van enkele maanden tot enkele uren. In de eerste twaalf maanden van intensief gebruik werden nog slechts acht niet-kritische fouten gevonden. Meetbare resultaten! Onderzoek Geen misverstand. Ongetwijfeld biedt ET zekere voordelen in bepaalde situaties. Maar, dan is het noodzakelijk te weten wat die voordelen zijn en in welke situaties dat geldt. Onderzoek. Maar, de conclusie blijft dat ET slechts een ander doekje voor het bloeden is. Een echte bijdrage zal zijn te investeren in de vroege fasen van een project, zodat testen teruggebracht kan worden tot normale proporties. Het is een activiteit om vast te stellen dat een product conform specificaties en ontwerp werkt. Maak de specificaties en het ontwerp sluitend, dan wordt testen een relatief eenvoudige formaliteit. AUTEUR: Hans Sassenburg Hans Sassenburg (hsassenburg@se-cure.ch) is zelfstandig adviseur. Hij voert tevens een promotieonderzoek uit aan de Rijksuniversiteit Groningen. Informatie over de beschreven praktijksituatie kan gevonden worden op www.verum.com. Erik van Veenendaal beschrijft in zijn zeer leesbare artikel ‘Exploratory testen: zinvol of onzin?’ een aantal voor- en nadelen van deze alternatieve benadering van testen. Naast de door hem aangevoerde nadelen is er echter nog een bezwaar aan te voeren, namelijk de eenzijdige benadering die testen ziet als activiteit met als enige doel het vinden van fouten. Exploratory testing (ET) richt zich voornamelijk zo niet uitsluitend op het vinden van fouten in een informatiesysteem. Wellicht de meest extreme uiting van dit principe komt van Cem Kaner, een van de grondleggers van ET, die opgemerkt schijnt te hebben: "A test that reveals a problem is a success. A test that did not reveal a problem was a waste of time." Uiteraard is er niets mis met het opsporen (en vervolgens verhelpen) van fouten in een nieuw of aangepast informatiesysteem. De bedrijfszekerheid van het desbetreffende systeem wordt er immers door verhoogd; een welkome situatie voor elke projectmanager en opdrachtgever. Het uitvoeren van testgevallen dient echter altijd nog een tweede doel, namelijk het vaststellen van de kwaliteit van het geteste systeem. Hierbij wordt op basis van de testresultaten een uitspraak gedaan over het al dan niet voldoen van het product aan bepaalde eisen. Hoe meer testgevallen ten aanzien van een bepaalde eis of een bepaalde functionaliteit een negatieve uitslag geven, hoe lager het kwaliteitsoordeel zal zijn. Voorwaarde voor het op die manier met succes kunnen meten van de systeemkwaliteit is dan natuurlijk wel dat de gebruikte testgevallen een redelijke afspiegeling zijn van de in een productiesituatie te verwachten omstandigheden. Het moge echter duidelijk zijn dat aan deze voorwaarde bij gebruik van ET niet wordt voldaan. Testers gaan bij ET immers zeer gericht op zoek naar fouten, en de testresultaten zullen dientengevolge een relatief hoog aantal fouten opleveren. Het gebruik van de aldus verkregen testresultaten voor een kwaliteitsmeting zal onvermijdelijk leiden tot een vertekend beeld in negatieve zin: de kwaliteit van het opgeleverde product wordt lager ingeschat dan zij in werkelijkheid is. Fouten Indachtig de hierboven geciteerde woorden van Cem Kaner over nuttige en nutteloze testgevallen levert een succesvol ET-traject in het ideale geval voor elk testgeval een defect. Bij de beoordeling van het al dan niet succesvol zijn van een testtraject is het aantal gevonden fouten dus van belang: hoe groter het percentage testgevallen dat een fout oplevert hoe succesvoller het testtraject is geweest. De vraag is echter of hiermee de kous af is. Want de volgende vraag die beantwoord moet worden is: kan het systeem in productie worden genomen: ja of nee? En hoewel we hierboven hebben gezien dat een hoog foutpercentage in een volgens ET uitgevoerde test niet hoeft te duiden op een hoog percentage aan fouten in het geteste systeem, is er geen enkele manier om aan te geven hoe hoog dit percentage dan wél is. Niet bepaald een geruststellende gedachte bij een systeem dat binnenkort in productie moet worden genomen. Het omgekeerde geldt echter ook. Als bij een testtraject dat volgens de ET-werkwijze is uitgevoerd erg weinig fouten worden gevonden, wat dan? Naar de letter der wet heeft het testtraject dan niet aan zijn doelstelling beantwoord en zit de testmanager met een probleem. Er is klaarblijkelijk niet goed genoeg gezocht naar fouten. Misschien was de materiedeskundigheid van de testers toch onvoldoende om ET met succes te kunnen toepassen. Of wellicht zijn veel fouten over het hoofd gezien als gevolg van foutieve interpretaties van de testers, of simpelweg door het ontbreken van een uitvoervoorspelling. Anderzijds kan het vinden van weinig fouten er natuurlijk ook op duiden dat er gewoonweg weinig fouten in het systeem zitten. Kortom: het uitgangspunt van ET dat met behulp van testen zo veel mogelijk fouten in zo kort mogelijke tijd moeten worden gevonden, klinkt in eerste instantie aantrekkelijk, maar kan de diverse verantwoordelijken voor een behoorlijk dilemma plaatsen. De verantwoordelijke voor het testen heeft zijn werk alleen goed gedaan als er ‘veel’ fouten worden gevonden. Dit stelt echter de eindverantwoordelijke(n) voor de oplevering van het systeem voor een heikele vraag: vrijgeven of verder testen (om nog meer fouten te vinden)? Als er daarentegen weinig fouten worden gevonden kan dit duiden op een weinig succesvolle test óf op een product waar weinig fouten in zitten. Testen volgens de principes van ET roept op die manier meer vragen op dan het beantwoordt. Doelstelling ET is weinig bruikbaar als methode om met behulp van testen de kwaliteit van een informatiesysteem te bepalen, en beantwoordt derhalve niet aan een van de doelstellingen die elk testtraject zou moeten hebben. Toch is het ook niet zo dat ET in alle gevallen als een volstrekt onbruikbare methode gekenschetst moet worden. Als aanvulling op de meer gestructureerde testmethoden of in extreme situaties (zoals door Van Veenendaal aangegeven) is ET wellicht een manier om althans nog iets met testen te bereiken, ook al blijft dat dan beperkt tot het naarstig opsporen van fouten. Maar ook in die specifieke situaties geldt dat we ET alleen zouden moeten toepassen ‘omdat we nou eenmaal iets aan testen moeten doen’. Of om met voormalig minister van Sociale Zaken Bert de Vries te spreken: "Als het niet kan zoals het moet, dan moet het maar zoals het kan." AUTEUR: Rob Henzen Rob Henzen werkt als (test)consultant bij Refis system reliability engineering te Bilthoven (www.refis.nl). Hij houdt zich voornamelijk bezig met betrouwbaarheidsanalyses van informatiesystemen, het opzetten en begeleiden van testtrajecten en het uitvoeren van audits op test- en ontwikkeltrajecten.