Kritiek op Exploratory testen voor deel struisvogelpolitiek
De reacties op het artikel ‘Exploratory Testen: zinvol of onzin?’ (Automatisering Gids 2 april) weerspiegelen in grote lijnen de interessante discussie zoals deze momenteel plaatsvindt in testland. Zoals altijd zijn er voor- en tegenstanders van een nieuwe ontwikkeling en bij het doornemen van meningen van de diverse auteurs zal de lezer zijn eigen mening kunnen vormen. Er zijn echter bij het goed bestuderen van de verschillende reacties ook een aantal overeenkomsten te vinden. Overigens is het opvallend dat er nog steeds IT’ers zijn die testen zien als uitvoeringsfase. Ook activiteiten zoals reviews, maken wat mij betreft onderdeel uit van het testproces. Oftewel, conform Hetzel: "alle activiteiten die gericht zijn op het vinden van fouten". Het wel of niet toepassen van ET moet een ‘risk-based’ beslissing zijn. Centraal staan bij de keuze de productrisico’s en het domein waarin de testactiviteiten dienen plaats te vinden. Elk goed testproject start met een inventarisatie van de productrisico’s en het bepalen van de componenten die bij falen de grootste business impact hebben. Vanuit deze kennis wordt een teststrategie opgesteld, waarbij op basis van een flink aantal factoren de concrete testaanpak wordt bepaald. Onderdeel van de testaanpak zijn de testtechnieken die passend zijn om de risico’s af te dekken. Sommige risico’s kunnen uitstekend worden afgedekt met ET, andere beter met meer traditionele testtechnieken. Ook het belang van testware zal de keuze voor wel of niet ET beïnvloeden. Overigens kunnen gedetailleerde testverslagen conform ET een goede basis vormen voor op te bouwen testware. Struisvogelpolitiek Veel tegenstanders betogen dat door middel van ET formeel geen kwaliteit kan worden aangetoond en dat het een stap terug is ten opzichte van de meer gestructureerde benadering. Is dat werkelijk zo? Uit eigen ervaring durf ik de stelling aan dat ‘minimaal 50 procent van de organisaties testscripts vervaardigen zonder gebruik te maken van gestructureerde testtechnieken’. Testscripts worden veelal ad-hoc, op basis van domein- en/of systeemkennis, vervaardigd (al wordt dit niet altijd als dusdanig toegegeven of onderkend). Voor al deze organisaties is ET wellicht een eerste stap op weg naar het toepassen van testtechnieken. Het ET testcharter is immers een formeel document, en kan worden gezien als een eerste aanzet tot een testontwerp. Ook het reviewen ervan met de betrokkenen is een uitermate zinvolle activiteit en zorgt voor betrokkenheid met het testproces. Kritiek leveren op de minder formele kant van ET, en vervolgens ad-hoc testscripts opstellen is wat mij betreft een vorm van struisvogelpolitiek. Natuurlijk is het zo ‘dat een succesvol testgeval een fout oplevert’. Dit is echter geen definitie van testen, maar een houding van de tester. Wij gaan er immers voor om fouten te vinden, vanuit die houding moet je werken om überhaupt fouten te kunnen vinden. Kan ET ook iets zeggen over de kwaliteit van het systeem, met andere woorden levert het ook (naast fouten) een kwaliteitsadvies? Door in de testcharters expliciet de af te dekken requirements op te nemen, is een redelijke uitspraak te doen over requirementsdekking door de uitgevoerde tests. Een goede bruikbare indicator bij ET over de kwaliteit van het systeem is ‘het aantal fouten per testuur’. Op basis van ervaringscijfers kunnen acceptatiecriteria worden gedefinieerd waartegen uitstekend kan worden gerapporteerd. Let wel, een ET-testset bestaat in principe niet op basis van een operationeel profiel, en zal dan ook geen toepassing hebben voor aspecten zoals performance en betrouwbaarheid. Grootste gevaar Bij een groot deel van de reacties die ik sinds de publicatie van het eerste artikel op 2 april mocht ontvangen, gaven de testers aan dat zij al lang exploratory testen deden, ‘alleen nu had het een naam’. Goed doorvragen leerde mij dat zij bijna allemaal gewoon error-guessing deden. Dit is voor mij het grootste gevaar van ET, testers die ET als excuus gebruiken voor het mogen testen zonder gedetailleerde scripts. Voor al diegenen die menen aan exploratory testen te doen is een korte vragenlijst bijgevoegd (zie kader) om vast te stellen of het nu echt exploratory testen betreft, of ‘slechts’ ongestructureerd error-guessing. Natuurlijk ben ik het (minimaal) ten dele eens met de stelling dat ET slechts symptoombestrijding is. Voorkomen is altijd beter dan genezen. Er zouden toch gewoon betere requirements moeten zijn, een goede projectplanning met voldoende tijd voor testen, metrieken vanuit de praktijk et cetera. Helaas is de echte wereld nog lang niet zover, en moeten we veelal overleven (testen) in minder volwassen organisaties. Hetgeen overigens niet wil zeggen dat we niet kritisch mogen zijn ten aanzien van de tekortkomingen in onze omgevingen. Daarnaast spelen time-to-market en kosten/batenverhoudingen een belangrijke rol bij het bepalen van de testaanpak. Er zijn systemen en marktsegmenten waar ET als techniek gewoon prima past. Zoals altijd is de discussie nog lang niet ten einde, en zal ook ET zich met de huidige aandacht nog verder ontwikkelen. Het is van belang goede en slimme keuzes te maken, gebaseerd op een gedegen kennis van gestructureerd testen en ET, maar vooral op basis van de marktsituatie en af te dekken productrisico’s. Tien vragen Als exploratory testen wordt toegepast, dienen de volgende vragen met ‘ja’ te worden beantwoord: 1 Worden tijdens de testvoorbereidingsfase testcharters opgesteld ten behoeve van de testsessies? 2 Wordt het testcharter uitgebreid gereviewed met de belanghebbende, ontwikkelaars en collegatesters? 3 Is er ter ondersteuning van de fase testuitvoering een uitgebreide lijst met testideeën (heuristics) en meest voorkomende fouten beschikbaar? 4 Worden de ET-activiteiten deels uitgevoerd door ervaren testers die reeds ruime kennis en kunde hebben ten aanzien van gestructureerde testtechnieken? 5 Worden de testsessies uitgevoerd in teams van twee personen? 6 Hebben de testsessies een maximale lengte van één dag (bij voorkeur minder)? 7 Worden er in de testsessies testverslagen gemaakt, onder andere in het kader van aantoonbaarheid, reproduceerbaarheid en eventueel ter opbouw van testware? 8 Worden in deze testverslagen ook de nieuwe productrisico’s en issues beschreven? 9 Vindt er dagelijks overleg plaats binnen het testteam om de ervaringen van die dag te bespreken? 10 Wordt op basis van het dagelijkse overleg bepaald wat de meest interessante testgebieden zijn voor de komende testperiode? Erik van Veenendaal is directeur van Improve Quality Services BV en internationaal erkend als expert op het gebied van testen. Hij is tevens als universitair docent verbonden aan de TU-Eindhoven (eve@improveqs.nl).Meer vragen dan antwoorden De essentie, positionering en toepassingsmogelijkheden van exploratory testen komen in het artikel van Erik van Veenendaal (AG 2 april) niet eenduidig uit de verf. Het artikel roept daarom evenveel vragen op als het beantwoordt. Er zijn met betrekking tot systeemontwikkeling meerdere soorten tests te onderkennen: programmatests; integratietests; acceptatietests; et cetera. Het wordt niet duidelijk waarop exploratory testen als testtechniek/methode betrekking heeft (alle testsoorten, een subset?). De positionering van het testen binnen de Application Life Cycle (bredere context) en de daaruit voortvloeiende wezensvraag ‘Waarom testen?’ blijven onvermeld.Waar het om gaat, is redelijk vervat in de vraag: Zijn er bij het omvormen van specificaties naar programmatuur voldoende preventieve maatregelen (check op kwaliteit ‘input’, ervaren programmeurs, naamgevingsconventies, codeer- & documentatiestandaards) en repressieve maatregelen (QA-rol, diverse soorten tests ter detectie & correctie van onvolkomenheden, feed back, peer reviews) aanwezig om te waarborgen dat het uiteindelijke programma voldoet aan de functionele wensen, kwaliteitseisen en randvoorwaarden? Wat voldoende is, is onder meer afhankelijk van de doelstelling en het risicoprofiel van de te ontwikkelen applicatie in kwestie. En bij de keuze van teststrategie, -diepgang et cetera is de kwaliteit van de andere (preventieve en repressieve) maatregelen mede richtinggevend. Er wordt gesproken over een vorm van exploratory testen aangeduid als exploratory testen ‘pur sang’. Klaarblijkelijk is er nog een andere smaak (‘non pur sang’?). De verschillen tussen beide smaken en welke variant in het artikel wordt behandeld, komen niet naar voren. Van Veenendaal schrijft dat er succesverhalen van exploratory testen zijn bij bepaalde soorten applicaties zoals games, Microsoft-producten et cetera. Als die succesverhalen er inderdaad zijn, mag hier een verklaring worden verwacht op basis van onderzoek waarom bij deze soorten applicaties succes kan worden geboekt. Wat zijn de gemeenschappelijke karakteristieken van deze soorten applicaties die als kritische succesfactoren voor ET fungeren? Heeft dat bijvoorbeeld te maken met de meer aanbodgedreven totstandkoming waarmee de kans kleiner is dat het systeem niet voldoet als gevolg van interpretatiefouten in de intermenselijke communicatie? Dergelijk onderzoek is klaarblijkelijk nog niet uitgevoerd, anders was er hier wel aan gerefereerd. Hetgeen het beeld oproept dat als ET al iets is, het waarschijnlijk (nog) niet veel meer is dan een hype. De auteur zegt dat binnen ET testonderwerpen zoals voorbereiding, uitvoering, rapportages, sessies in ruime mate aan bod komen. Verderop wordt gesteld dat testplanning niet is beschreven en formele fasering ontbreekt binnen ET. Het is derhalve raadzaam te definiëren waar ET in ruime mate aandacht aan schenkt bij het voorbereiden, uitvoeren et cetera. Onduidelijk Er wordt gesproken over toepassingsgebieden waar ET kan worden gecombineerd met de meer gestructureerde testaanpak en in dat verband wordt een vijftal omstandigheden genoemd. Welke elementen van ET met welke van de gestructureerde aanpak zijn te combineren voor elk van de omstandigheden, blijft onduidelijk. De eerstgenoemde omstandigheid betreft het niet of onvoldoende beschikbaar zijn van specificaties. Er wordt aangegeven dat ET een oplossing biedt, maar dat veel materiekennis nodig is. Ik zou dit afgezet willen zien tegen de variant waarin de materiedeskundige alsnog de spec’s ophoest (en vastlegt) waarna op gestructureerde wijze wordt getest. De tweede en derde omstandigheid zijn optisch identiek; beide betreffen tijd als schaarse factor. (Het is sowieso de vraag of je de eerste drie omstandigheden moet willen of accepteren in een ontwikkeltraject.) Bij de vierde omstandigheid wordt gesproken van bepaalde typen fouten die soms alleen zijn te vinden met informele technieken. Het begrip fout blijft ongedefinieerd. Gaat het bij fouten om onjuiste werking of om functionaliteit die niet volledig voldoet aan de wensen, eisen en randvoorwaarden of om inefficiënte manieren van coderen? Omstandigheid vijf, over de benodigde systeem- en domeinkennis, is eerder een voorwaarde voor ET dan een situatie waarin ET uitstekend past in de zin dat het is te prefereren boven of een goede aanvulling is op de gestructureerde aanpak. Bij de beschrijving van het nadeel dat bij ET relatief veel schaarse tijd aan de testuitvoering wordt geschonken door het ontbreken van een testontwerp, lijkt voorbij te zijn gegaan aan het feit dat het opstellen van het testontwerp ook tijd vergt; het tijdverlies bij de uitvoering wordt derhalve gecompenseerd door de tijdwinst in de voorbereiding. Ergens ligt dus een optimum als het doel is de hoeveelheid testtijd te minimaliseren. Het artikel stelt dat het ontbreken van uitkomstvoorspellingen bij ET als nadeel heeft dat fouten onopgemerkt blijven. Gevoelsmatig is de dieperliggende essentie hier de beperkte mate van assurance als gevolg van een minder gestructureerde testaanpak bij ET. Drs. A.F.Th. Laan RE (ad.laan@kasbank.com) is Hoofd IT-Audit bij Kas Bank N.V. te Amsterdam.