Hoewel exploratory testing (et) in de Verenigde Staten als begrip al enkele jaren bestaat, is het pas vrij recent naar Europa komen overwaaien. Bij deze manier van testen worden de tests niet meer vooraf bedacht en opgeschreven, maar worden testontwerp en testuitvoering gecombineerd. De zoveelste hype uit Amerika, of hebben we er écht iets aan?
Testen, ofwel het beoordelen of het opgeleverde systeem (testobject) voldoet aan de vereisten (testbasis), is een onlosmakelijk onderdeel van de systeemontwikkeling. Tests zijn nodig om inzicht te geven in de kwaliteit van het systeem en de risico’s bij het in productie nemen.
Om het testen beheersbaar te houden, hanteren de meeste grote Nederlandse organisaties een methodiek voor gestructureerd testen. Voorbeelden van deze methodieken zijn Tmap en Testframe. Al vóór de oplevering van het testobject leiden de testers op basis van technieken testgevallen af uit de testbasis, bijvoorbeeld het functioneel ontwerp. Deze testgevallen worden beschreven en in uitvoerbare volgorde in testscripts geplaatst. Hierdoor kan de eigenlijke test in een zo kort mogelijke tijd worden uitgevoerd.
De laatste jaren zien we steeds meer informele systeemontwikkeltrajecten, met namen als ‘rad’, ‘dsdm’ of ‘extreme programming’. Dit betekent een probleem voor het testen: als er al een beschreven testbasis is, komt deze meestal pas laat beschikbaar. Het valt voor de tester dan ook niet mee om testgevallen af te leiden, want hoe kan hij of zij nu beoordelen of er voldoende testgevallen zijn én of de uitkomst van een testgeval goed of fout is?
School
In de VS is de trend voor informele trajecten al langer aan de gang en is er een hele school van testers ontstaan die het ontbreken van een testbasis niet meer ziet als iets ongewensts, maar als iets vanzelfsprekends. Exploratory testing komt voort uit deze school van denken. James Bach komt de eer toe om et als begrip te hebben geïntroduceerd. Hij heeft als eerste de aanpak beschreven.
Volgens Bach is et "any testing to the extent that the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests" (‘een vorm van testen waarbij de tester het ontwerp van de tests actief controleert terwijl die tests worden uitgevoerd en waarbij hij of zij de informatie uit die tests gebruikt om nieuwe, betere tests te ontwerpen’ – red.). Dit betekent dat de tests niet meer van tevoren worden ontworpen en opgeschreven, maar tijdens de testuitvoering worden bedacht. Opschrijven is feitelijk niet meer nodig. Tijdens het testen denkt de tester gelijk na over wat hij of zij nog meer kan testen.
Om het belang van dit voortschrijdend inzicht duidelijk te maken, maakt Bach de analogie met een legpuzzel. Bij een legpuzzel begin je eerst met een ruwe sortering van de stukjes, bijvoorbeeld hoeken, zijkanten en overig, daarna sorteer je op kleuren, enzovoorts. Het lukt nooit om in één keer alle stukje op zijn plaats te krijgen, je begint met enkele stukjes en probeert dat steeds uit te breiden met nieuwe stukjes.
Gestructureerd of ad hoc?
Is et nu wezenlijk anders dan ongestructureerd testen? Is het een aanvulling op gestructureerde testmethodieken of vervangt het juist de bestaande methodieken? We zetten een aantal voors en tegens van et op een rij.
Zo stellen de voorstanders dat et wel degelijk structuur kent, ook al is die vrij los. Et is niet hetzelfde als ongestructureerd, ad hoc testen. Zo kent et doelstellingen, taken en op te leveren producten. Een tester krijgt telkens een doelstelling mee, bijvoorbeeld ‘onderzoek de werking van een bepaald scherm’. Door de doelstellingen goed te kiezen, wordt voorkomen dat testers dezelfde zaken dubbel testen. Gedurende een bepaald aantal uren exploreert de tester dan de functionaliteit van het scherm en meldt de geconstateerde bevindingen. Afhankelijk van de gewenste mate van bewijs, kan bijvoorbeeld ook nog worden vastgelegd wat nu ongeveer getest is in de beschikbare tijd. Maar als het even kan wordt de hoeveelheid testdocumentatie zo klein mogelijk gehouden.
Tegenstanders stellen dat het gaat om de kleren van de keizer. In hun ogen is et het ‘goedpraten van ongestructureerd testen’. Ze betogen dat het testproces moeilijker beheersbaar, meetbaar en toetsbaar (auditable) is, omdat geen testgevallen worden gedefinieerd en omdat aan de logging van tests lagere eisen worden gesteld dan wanneer wordt getest aan de hand van scripts. Ofwel, je weet niet wat de tester gaat doen, hoe hij of zij het gaat doen en achteraf is nauwelijks controleerbaar wat er gedaan is.
We kunnen echter vaststellen dat het op ongestructureerde manier zoeken naar fouten in het systeem al jaren wordt toegepast als een nuttige aanvulling op gestructureerde testtechnieken. Het staat bekend als ‘error guessing’. Et heeft grote voordelen boven ‘error guessing’. Het is wél afhankelijk van de situatie hoe groot de ‘scheut’ et in het gestructureerde testproject moet zijn. Deze kan variëren van 5- tot 100 procent.
Altijd en overal?
Vrijwel altijd kan één of andere vorm van et worden toegepast. Bach stelt dat et toegepast kan worden wanneer de volgende test niet voor de hand ligt, of wanneer je meer wilt doen dan de voor de hand liggende tests. Volgens hem is dat meestal het geval. Et moet worden toegepast wanneer er op korte termijn inzicht nodig is in de productkwaliteit, wanneer de testers snel willen leren hoe het systeem werkt, om variatie buiten de testscripts aan te brengen, om de kwaliteit van andermans testen te beoordelen met een korte steekproef of om een specifieke bevinding of specifiek productrisico te onderzoeken.
Enige uitzonderingen zijn de situaties waarin er extreem hoge eisen worden gesteld aan de aantoonbaarheid en vastlegging van testen, zoals bij ‘life-critical’ software, of wanneer de ‘feedbackloop’ erg zwak is. Met dit laatste wordt bedoeld dat de testresultaten niet direct beschikbaar zijn, zoals bijvoorbeeld bij het testen van batchprogrammatuur.
De tegenstanders stellen dat et alleen geschikt is als de testbasis onvoldoende is. Als er wél een degelijk functioneel ontwerp of een grondige definitiestudie is, dan verdient een methodische aanpak met voorbereide testscripts de voorkeur. Dat deze tests wellicht voor de hand liggen, wil niet zeggen dat ze niet nodig zijn, integendeel!
En er zijn nog vele andere omstandigheden waarin et niet voor de hand ligt. Dit zijn situaties die veel voorbereiding(stijd) vergen, zoals het testen van ingewikkelde berekeningen, performancetesten, het testen van beveiliging of het testen van ‘usability’. Deze voorbereidingen kunnen beter ruim vóór testuitvoering plaatsvinden, om niet onnodig veel tijd kwijt te zijn t�jdens testuitvoering.
Niettemin is et een nuttige aanvulling op testen aan de hand van scripts, om creatief testen te stimuleren. Vaak zitten de fouten in de software op onverwachte plaatsen. Formele testspecificatietechnieken zijn gericht op het vinden van bepaalde typen fouten. Het gebruik van deze technieken kan gezien worden als een filter waar de software doorheen wordt gegooid. Met elke filter, lees: testspecificatietechniek, blijven bepaalde typen fouten achter. Door de informele aard van et is deze testmethode minder gericht op bepaalde typen fouten. Bij een fout die met et is gevonden, moet de tester zich goed afvragen of de fout uniek is of dat hij ook op allerlei andere plaatsen kan voorkomen.
Goede testers nodig
Wat voor persoon is de exploratory tester? Om ter plekke goede tests te bedenken en uit te voeren, zijn goede testers nodig. Et stelt hoge eisen aan de inventiviteit en kunde van de tester en haalt op die manier het beste in de testers boven. Deze mensen hebben voldoende testervaring, met grondige kennis van zaken als ’testdekking’ en testtechnieken. Zij gebruiken hun kennis van technieken impliciet, dat wil zeggen dat ze die niet nodig hebben om hun testgevallen van tevoren uit te schrijven. Hoogstens werken ze met globale checklists van mogelijke tests, bijvoorbeeld op welke manieren je een invoerveld kunt controleren.
De tegenstanders vinden het een groot nadeel dat et alleen geschikt is voor zeer ervaren testers, die niet hoeven op te schrijven wat ze testen. Het probleem met deze redenering is dat het moeilijk is vast te stellen of iemand een goede tester is. Ben je dat wanneer je een cursus testtechnieken hebt gevolgd, of een certificaat hebt behaald, of omdat je al X jaar testervaring hebt? Ook is in de praktijk bij de meeste testen kennis van het systeem en de business nodig, naast pure testkennis. Dit betekent dat ook ontwikkelaars en gebruikers worden ingezet als testers. Deze op testgebied vaak ondeskundige personen worden door de grote mate van vrijheid van et onvoldoende gesteund om een goede test uit te voeren. Zonder houvast van het expliciet toepassen van testtechnieken, resulteert dit in nietszeggende tests.
De praktijk wijst overigens uit dat gebruikers, ontwikkelaars en junior-testers met goede coaching betrekkelijk snel mee kunnen draaien in het testen. Een goede manier om dergelijke testers in te zetten op et, is om in paren te testen, dus een gebruiker of junior-tester samen te laten testen met een ervaren tester.
Effectiever en efficiënter
De voorstanders stellen dat met et in korte tijd veel meer bevindingen gedaan kunnen worden dan wanneer op basis van testscripts wordt getest. Stel, je hebt acht uur om een bepaalde groep van functies of schermen te testen. Wat levert dan meer op: acht uur lang de functies op allerlei explorerende manieren doorlopen en in te zoomen wanneer iets er verdacht uitziet, of de helft van de tijd besteden om een aantal testgevallen op te schrijven en die in de resterende tijd nauwgezet uit te voeren?
Tegenstanders vinden dat door de vrijheid van de tester om te bepalen wat hij of zij test, en de grote nadruk op de kwaliteit van de individuele tester, er weinig inzicht is in wat nu wel of niet getest is, en hoe grondig. Het is daarmee heel moeilijk om een uitspraak te doen over de effectiviteit van de test. De link tussen testen en de af te dekken productrisico’s is daarmee minder helder, of het wordt in ieder geval in grote mate aan de tester overgelaten om hierin keuzes te maken. Hierdoor wordt misschien wel meer getest, maar worden niet perse de belangrijke fouten gevonden. Omdat testontwerp en -uitvoering door elkaar lopen, kan bij et het testen pas laat beginnen, namelijk nadat het te testen systeem is opgeleverd. Meestal is dit op het kritieke pad van het project. Dit kost meer doorlooptijd dan wanneer er al testscripts voorbereid zijn.
Beide partijen hebben natuurlijk gelijk en in veel gevallen is een combinatie van et met gestructureerde testmethodieken een voor de hand liggende oplossing, waarin de ‘best of both worlds’ samenkomen. Wat hierin de verhouding moet zijn tussen et en de meer formele technieken, is dan afhankelijk van de situatie.
Geen vrijbrief
Is et nu een oplossing of een hype? Et is zeker geen ‘silver bullet’ voor alle testproblemen, maar evenmin een hype. Het kent een aantal grote voordelen, maar er zijn wel degelijk ook nadelen aan verbonden. Et is in ieder geval geen vrijbrief voor ongestructureerd testen, testdeskundigheid staat hoog in het vaandel. Gestructureerd testen is ook nog allerminst overbodig en in veel situaties ligt de combinatie van et met gestructureerd testen voor de hand.
De tot nu opgedane praktijkervaringen met et zijn heel positief. Ik wil de betrokken lezer dan ook graag oproepen om et een kans te geven, het uit te proberen en om het, geheel in stijl, te exploreren. Een succesvolle ontdekkingsreis toegewenst!< BR>
Op http://www.satisfice.com is uitgebreide informatie te vinden over exploratory testing. De auteur geeft op 10 juni een lezing over exploratory testing voor de regio Noord-Nederland van de Ngi: http://www.ngi.nl/noord
Tim Koomen, r&d manager Sogeti
