Als ervaren testconsultants weten wij – Jantien en Linda – dat er één vraag is die bij iedere klant waar exploratory testing (ET) toegepast wordt of gaat worden, centraal staat. Namelijk: Hoe toon je kwaliteit aan? En bij de testers die het toe (gaan) passen heersen de vragen: Hoe creëer ik vertrouwen? En: Pas ik (h)ET goed toe? In dit blogartikel, afgeleid van de gelijknamige presentatie de we gegeven hebben op de kennissessie Bijtanken bij Bartosz, geven we een antwoord op deze drie cruciale vragen.
Wat is exploratory testing?
We beginnen bij het begin. Wat houdt ET eigenlijk in, wat is de definitie? Heeft het te maken met het zoeken naar bugs? Gaat het over het verkennen van onbekend terrein? Of kunnen we het simpelweg ‘ongestructureerd’ noemen? TMap® Next en ISTQB beschrijven ET als iets wat je binnen een bepaald kader doet. Je maakt een checklist of charter en gaat met een timebox de software bekijken terwijl je klikt, om vervolgens testscripts te maken terwijl je test. Binnen Agile werken wordt het gezien als iets wat goed past bij het snelle karakter van agile testen, en wat past bij ‘niet meer documenteren’. Wikipedia beschrijft het als “A way to simultaneously learning, test design and execution”. Maar ET is veel meer dan dat. Het staat – net als bij Agile werken – zeker niet gelijk aan niet documenteren. Maar wat is het dan wel?
Exploratory testing volgens Jantien: Continu testideeën genereren
Bij Jantien staat het genereren van testideeën centraal. Een testidee is een vraag die je hebt aan/over het systeem waar je graag een antwoord op hebt, al dan of niet aangevuld met de manier waarop je hier achter wil komen. Het genereren van testideeën begint al wanneer de probleemstelling vanuit de business bekend wordt. Wanneer hiervoor een story aangemaakt is op de backlog en deze gevuld wordt met meer informatie, is dit een bron voor nóg meer testideeën. De volgende fases, waarin het hele team zich buigt over de functionaliteit, mogelijke oplossingsrichtingen en de risico’s van de keuzes, worden door het stellen van de juiste vragen veel van de testideeën scherper. Sessies zoals de 3-amigo sessies en de refinement vullen de bak met testideeën aan. Wanneer het betreffende backlog item opgepakt wordt in de sprint, begint Jantien met een getimeboxte sessie, waarin zij een thema, heuristiek of mnemonic neemt om zich op te focussen en haar creativiteit op los te laten. Denk bijvoorbeeld aan het thema Persona’s, waarbij je niet alleen kunt denken aan de eindgebruiker en de beheerder, maar ook over de “klant met haast” of “ontevreden medewerker”
De volgende stap is om al die testideeën te prioriteren en vervolgens een ET sessie te beginnen om de meest belangrijke vragen, onzekerheden te beantwoorden. Maar tijdens in zo’n sessie, krijg je vaak allerlei nieuwe testideeën. De truc is echter om je focus te houden. Blijf op het (test)pad richting je doel: het beantwoorden van de vraag waarmee je de sessie inging. Alle ideeën die je gaandeweg krijgt, noteer je en komen in de ‘bak’ met de andere, nog niet beantwoorde vragen. Aan het eind van de ET sessie stel je je de vraag: Heb ik voldoende vertrouwen in het stukje software dat ik getest heb? Zo ja, dan kun je door. Zo nee, wat wil je dan nog weten van/over het systeem om wél dat vertrouwen te krijgen? En gaat dat lukken in de beschikbare tijd? Terug naar de stapel testideeën, die nu mogelijk is aangevuld met nieuwe vragen uit de laatste sessie. Opnieuw prioriteren en een nieuwe ET sessie. Net zo lang tot je genoeg vertrouwen hebt en dit kunt uitleggen. Of tot de tijd op is, maar dat is een verhaal voor een andere keer.
Wanneer je ‘klaar’ bent met testen, geef je een test debriefing aan je team en andere betrokkenen. Je legt hier uit welke vragen je hebt gesteld en waarom. Welke antwoorden je hebt gevonden. Welke vragen je niet hebt kunnen beantwoorden en waarom niet. Tenslotte vraag je aan alle aanwezigen: Hebben jullie nog vragen aan het systeem in deze context? Hebben jullie voldoende inzicht in het testproces en vertrouwen in de aanpak? Hebben jullie voldoende vertrouwen in het systeem om hier mee live te gaan? Zo niet, waarom niet en wat kunnen we doen om dat te verbeteren? (Nieuw testidee!) Op deze manier zorg je voor een gedragen verantwoordelijkheid en expliciet uitgesproken vertrouwen. Als het vertrouwen er in het team is, gaat de software door naar de sprint review en ook daar wordt na een demo gevraagd of de business voldoende vertrouwen heeft in de op te leveren functionaliteit.
Exploratory testing volgens Linda: Focussen op het vaststellen van de kwaliteit
In de definitie van Linda staat het vaststellen van de kwaliteit centraal. Zij probeert eerst aan te tonen dat het werkt. Wat ‘het’ in dit geval is? Het systeem, de functie, de module, het proces. Wat op dat moment ook het testobject is. Afhankelijk van het proces kan het verschillen of dat een sprint backlog item is, of dat ze als acceptant namens de klant de oplevering van de leverancier test. Als het gelukt is aan te tonen dat het werkt, dan volgt het waarom. Waarom werkt dit eigenlijk? Is het toeval dat het goed ging? Kan het op een andere manier ook lukken? Als testers weten we: vaak lukt het niet om aan te tonen dat het werkt. Je komt een bug tegen, of kan geen bewijs vinden waarom het werkt. Daarna switch je naar: aantonen dat het niet werkt. Ook daarbij geldt: aantonen waarom het niet werkt is net zo moeilijk als aantonen dat het wel werkt. Met ET kun je veel informatie verzamelen over het gedrag van het systeem. Of het werkt, wat je ermee kan. Of je er vertrouwen in kunt krijgen. Is het een hele functie of module die niet werkt? Of alleen een bepaalde gegevensset?
Een hele belangrijke invalshoek die Linda inzet, zelfs los van of het wel of niet werkt: Wat is het nut of de noodzaak van de software? Gaat en kan het gebruikt worden zoals het bedoeld is? Is er behoefte aan en is het bruikbaar voor de doelgroep? Uiteindelijk geeft Linda aan haar klant een duidelijk advies over de kwaliteit en de risico’s die er eventueel nog zijn. Daarbij staan het voorgenomen gebruik en de bruikbaarheid centraal.
