Als we naar de definitie kijken dan kunnen we direct zien dat exploratory testen meer is dan “zomaar even wat proberen”. Toch wordt dit laatste wel met exploratory testen geassocieerd. In eerste instantie lijkt het erop dat de tester zomaar wat doet en er totaal geen structuur is in de uitvoering van zijn tests.
Vanuit testoptiek ben ik daar anders tegenaan gaan kijken. Tijdens de testuitvoering komt het meer dan eens voor dat de testbasis niet optimaal is, vaak zijn cruciale gegevens zoals requirements, functioneel ontwerp en technisch ontwerp niet of onvoldoende aanwezig. In sommige gevallen kan de tester op andere manieren de testbasis uitbreiden tot een volledig geheel (volledig als in testbaar) en in andere gevallen is dit niet mogelijk door gebrek aan kennis en/of tijd.

Door de ontbrekende testbasis en/of de beperkingen die opgelegd zijn aan het testproces is het niet altijd mogelijk om bijvoorbeeld een volledige procescyclus test of elementaire vergelijkingen test uit te voeren. De tester zal dan zijn toevlucht moeten doen op de belangrijkste testtechniek binnen TMap, de exploratory test. De enige moeilijkheid die rest is het juist toepassen van de techniek. Pas als de exploratory testtechniek goed wordt toegepast, dan wordt de waarde vele malen hoger dan het “zomaar even proberen”.

Zoals de definitie voorschrijft is het belangrijk dat iedere volgende test zijn lering moet trekken uit de voorgaande testuitvoering. Dit wordt gedaan door tijdens de testuitvoering gedetailleerd bij te houden wat je gedaan hebt (dit is tevens het reproductiepad voor de ontwikkelaars). Door een specifiek testdoel op te stellen kun je tijdens de testuitvoering alle stappen doorlopen om dat specifieke doel te halen. Door na iedere test te evalueren welke bijzonderheden je tegengekomen bent (of welke paden je wel/niet hebt doorlopen), kun je nieuwe testdoelen opstellen. Pas als er geen nieuwe testdoelen tegen gekomen worden en alle bestaande testdoelen zijn expliciet in een exploratory test uitgevoerd, kan de tester al zeer veel zeggen over de kwaliteit van het systeem.

Praktisch ben je dus tijdens de testuitvoering bezig met het ontwerpen van de test. Dit vang je in een testcharter. Een testcharter bestaat ten minste uit de volgende onderdelen:

-Wat is het doel / beoogde resultaat van deze test;

-Welke stappen heb ik doorlopen om het doel / beoogde resultaat te behalen;

-Welke bevindingen heb ik opgedaan;

-Korte evaluatie van de uitgevoerde test / wat heb ik geleerd over het systeem;

-Welke nieuwe concrete testdoelen kan ik bedenken op basis van deze testuitvoering.

De tester kan na een paar testcharters precies verwoorden wat hij gedaan heeft, hoe hij dat gedaan heeft en waarom hij dat op die manier heeft gedaan.
Mijns inziens kan iedere willekeurige test uitgevoerd worden met exploratory testen. Resultaten worden op een gestructureerde manier verzameld en juist zonder volledige testbasis is de techniek uitstekend inzetbaar. De exploratory test kan veel tijd besparen die normaal voor specificatie gebruikt wordt. Tevens vinden de testen nog meer op het kritieke pad plaats waardoor ontwikkelaars nog sneller feedback krijgen op het door hen geleverde stuk software. Wel moet aangegeven worden dat deze testtechniek geen vervanging is voor de andere 13 testtechnieken. Dit omdat de ervaring van de tester mede bepaalt hoe volledig de exploratory test is uitgevoerd en het moeilijker is om iets te vertellen over de dekkingsgraad van de test. Het is dus zeer verstandig om vooraf goed te bepalen welke deelproducten op welke wijze getest gaan en moeten worden.