03 nov 2026 Exploratief testen: wat het vindt dat gescripte tests missen, en hoe je het plant

In het kort: Bij exploratief testen bedenkt een tester de tests terwijl hij ze uitvoert, en leert hij de software kennen onderweg. Zo vind je fouten waar geen eis voor is geschreven, zoals onduidelijke schermen en vreemde combinaties. Plan het met een doel, een vaste tijd en aantekeningen. Automatisering bewaakt wat je weet, exploratief testen vindt wat je niet weet.

Elke test in je geautomatiseerde set is geschreven door iemand die al wist wat hij wilde controleren. Dat is de kracht ervan, en ook de grens. Gebruikers volgen je testgevallen niet. Ze klikken halverwege terug, plakken rare tekst in een veld en openen twee tabbladen tegelijk. Met exploratief testen vindt een ervaren tester die problemen voordat je gebruikers dat doen. Goed gedaan is het een van de nuttigste dingen die een tester kan doen.

Wat is exploratief testen?

Exploratief testen is testen waarbij je de volgende test bedenkt op basis van wat de vorige je leerde. Er ligt vooraf geen script klaar. Een tester krijgt een doel mee, zoals “zoek uit hoe het nieuwe terugbetaalscherm met fouten omgaat”, en gaat de software gebruiken. Wat hij ziet, bepaalt wat hij daarna probeert. Accepteert een veld een negatief bedrag, dan duikt hij daarin. Is een foutmelding onduidelijk, dan kijkt hij waar die nog meer opduikt. De ISTQB-woordenlijst omschrijft het als testen waarbij de tester tests ter plekke ontwerpt en uitvoert, op basis van kennis en wat hij leert. In het Engels heet het exploratory testing. Dat klinkt vrij, maar goed exploratief testen heeft een duidelijke structuur. Het verschilt van willekeurig rondklikken zoals een onderzoek bij de huisarts verschilt van een gok.

Gescript testen werkt precies andersom. Iemand schrijft eerst de stappen en het verwachte resultaat op, en de test volgt die. Daardoor zijn gescripte tests herhaalbaar en goed te automatiseren. Het betekent ook dat ze alleen controleren waar de schrijver aan dacht.

Wat vindt exploratief testen dat gescripte tests missen?

Het vindt de fouten die tussen de eisen in zitten. Een gescripte test controleert of een regel werkt zoals hij is opgeschreven. Iemand die exploratief test, ziet wanneer die regel voor een gebruiker nergens op slaat, of wanneer twee regels botsen. Juist die bevindingen leiden na een release vaak tot telefoontjes bij de klantenservice. Dit zijn typische voorbeelden.

• Onduidelijke schermen. Elk veld werkt, maar een nieuwe gebruiker weet niet wat hij nu moet doen.
• Vreemde combinaties. Een kortingscode plus een cadeaukaart plus een geannuleerd artikel.
• Onderbroken processen. De terugknop, een time-out of een tweede tabblad midden in een betaling.
• Zeldzame randgevallen. Heel lange namen, speciale tekens, de laatste dag van de maand. In ons stuk over edge cases testen lees je hoe duur die kunnen worden.
• Gaten tussen systemen. De bestelling is opgeslagen, maar de bevestigingsmail toont de oude prijs.

Sommige hiervan kan alleen een mens beoordelen. Of een scherm duidelijk is, of een gebruiker eruit komt, is een menselijk oordeel. Bij alles met een gebruikersinterface telt dat nog zwaarder.

Hoe plan je exploratief testen zodat het meer is dan rondklikken?

Geef elke sessie een doel, een vaste tijd en een kort verslag. Deze aanpak heet vaak session-based test management, een methode van James en Jonathan Bach. Het doel schrijf je op als testcharter: één regel over wat je onderzoekt en waar je op let. De vaste tijd houdt de sessie gericht, vaak 60 tot 90 minuten. De aantekeningen maken het werk zichtbaar, zodat een testcoördinator ziet wat er is gedekt. Deze stappen werken in de meeste teams.

1. Schrijf een testcharter. Bijvoorbeeld: “Onderzoek de terugbetaling bij gedeeltelijke retouren, op zoek naar verkeerde bedragen.”
2. Spreek een tijd af. Kies een lengte en stop als die om is, ook midden in een gedachte.
3. Maak onderweg aantekeningen. Wat je probeerde, wat je vond en welke vragen opkwamen.
4. Bespreek het tien minuten na. Deel wat je vond met een developer of de product owner.
5. Bepaal het vervolg. Een bugmelding, een nieuwe charter of een nieuwe geautomatiseerde test.

Plan sessies waar het risico het grootst is. Nieuwe functies, onderdelen die flink zijn veranderd en processen met geld of persoonsgegevens zijn goede plekken om te beginnen. Het boek Explore It! van Elisabeth Hendrickson staat vol praktische ideeën voor charters.

Hoe werken exploratief testen en testautomatisering samen?

Ze doen elk een ander werk, en ze maken elkaar beter. Automatisering controleert steeds opnieuw of wat gisteren werkte, vandaag nog werkt. Dat is het werk van de regressietest. Exploratief testen zoekt naar wat niemand wist te controleren. Vindt een sessie een ernstige bug, dan krijgt de oplossing een geautomatiseerde test. Zo kan het probleem niet ongemerkt terugkomen. En als de regressieset elke nacht vanzelf draait, hebben testers tijd om te onderzoeken in plaats van dezelfde controles met de hand te herhalen.

Onze case Government Operations Centre laat die mix zien. Het platform veranderde steeds en had geen regressietests. Met use case testen en exploratief testen werden nieuwe functies gecontroleerd en onverwacht gedrag gevonden. Selenium automatiseerde de regressietests voor de kernfuncties in meerdere browsers. Na elke testcyclus kreeg de klant een releaseadvies.

AI verandert die verdeling niet. AI kan een user story lezen en een eerste opzet van testgevallen maken, en dat scheelt tijd aan de gescripte kant. Maar een mens blijft zelf nadenken over wat ertoe doet, wat ontbreekt en wat niet klopt. Exploratief testen vanuit een echte gebruiker blijft mensenwerk, net als acceptatietesten door je gebruikers uit de business. Meer daarover lees je in ons stuk over AI testen.

Exploratief testen heeft ook grenzen. Je kunt een sessie niet precies herhalen, en de uitkomst hangt af van de tester. Het is ook lastiger om over te rapporteren dan een percentage geslaagde tests. Charters en aantekeningen lossen een deel daarvan op, maar niet alles. Gebruik het dus niet als je enige vangnet voor wat moet blijven werken. Daar is automatisering voor.

Wat betekent dit voor je team?

De meeste teams vinden exploratief testen waardevol. Toch is het vaak het eerste dat sneuvelt als een release krap wordt. Testers zijn hun dagen kwijt aan handmatige regressiecontroles, en er blijft geen tijd over om te onderzoeken. Of het team heeft helemaal geen tester, en developers testen hun eigen werk met de stappen die ze al in hun hoofd hadden.

Twee dingen helpen. Automatiseer het herhaalwerk, zodat mensen tijd terugkrijgen. En zorg dat iemand in het team de kennis en de ruimte heeft om te onderzoeken. Via QA & Testen voegen we ervaren testers aan je team toe voor precies dat werk. Ze plannen sessies waar het risico zit, melden wat ze vinden in gewone taal en maken van belangrijke bevindingen tests die blijven draaien.

Een eerste stap voor deze week: kies de functie waar je het minst zeker over bent. Schrijf er één charter voor, plan 90 minuten in en kijk wat je vindt.

Veelgestelde vragen

Wat is het verschil tussen exploratief testen en ad-hoc testen?

Ad-hoc testen heeft geen plan en geen verslag. Exploratief testen heeft een doel, een vaste tijd en aantekeningen, zodat je weet wat er is gedekt en gevonden. De vrijheid zit in hoe de tester het doel bereikt.

Kun je exploratief testen automatiseren?

Nee. De waarde zit in een mens die reageert op wat hij ziet. Wat je wel automatiseert, zijn de controles die eruit voortkomen. Zo bewaak je een bug die je één keer vond in elke run daarna.

Wie doet het exploratieve testwerk?

Iemand die weet hoe gebruikers werken en hoe software meestal faalt, vaak een ervaren tester. Developers en gebruikers uit de business kunnen aanschuiven. Een frisse blik ziet vaak wat de bouwers niet meer zien.

Hoe rapporteer je over exploratief testen?

Rapporteer per sessie: de charter, de bestede tijd, wat er is gedekt, de gevonden bugs en open vragen. Een kort overzicht van sessies per functie laat een testcoördinator zien waar de gaten nog zitten.