Testautomatisering, Tooling

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.

Ontwerp zonder titel (3)

Dé definitie of methode bestaat niet

Jantien en Linda voeren allebei op een andere manier ET uit. Het mooie is, beide manieren zijn goed. Er bestaat namelijk niet zoiets als dé definitie of dé methode. De methode van Jantien is Jantien’s methode en die is goed. De methode van Linda is Linda’s methode en die is ook goed. Zij vinden dat de theorie over ET, zoals deze vaak in boeken staat en in trainingen wordt gegeven, goede handvaten kan geven maar als er te strikt aan vastgehouden wordt, het beperkend is voor de creativiteit die elke tester met zich meebrengt. Op basis van jouw kennis en ervaringen, creëer je jouw eigen methode. Waarbij de gemene deler is dat we uiteindelijk allemaal vertrouwen willen creëren. In jouw testproces en in het systeem. Hóe je vervolgens ET toepast om dit voor elkaar te krijgen, is aan jou.

De vijf belangrijkste vaardigheden bij het creëren van vertrouwen

Wij horen je denken: “Vertrouwen creëer ik toch door het vinden van bugs, door te rapporteren, door een hoge testdekking, het uitgevoerde aantal testcases of code coverage?” Niet dus! Dit is een valkuil waar al velen van ons zijn ingestapt. Zegt het aantal bugs dat je vindt iets over de kwaliteit? Zorgt een testrapportage ervoor dat je de software wel of niet vertrouwt? Nee. Het zijn slechts metagegevens die niet direct iets zeggen over de kwaliteit. Het zijn gegevens die de karakteristieken van een functionaliteit beschrijven, of die iets zeggen over je project voortgang (tijd/budget). Het zegt niets over of jij als test engineer de software vertrouwt.

Vertrouwen creëer je wél door de volgende vijf vaardigheden toe te passen:

  • Stel vragen. Wat wil je weten van het systeem? Welke risico’s wil je onderzoeken? Wat is er belangrijk voor de eindgebruiker? Wat gebeurt er als ik afwijk van de ‘werkinstructie’?
  • Laat zien. Neem je team, je stakeholders of de klant mee in welke vragen je gesteld hebt, wat de antwoorden hierop zijn en hoe je tot die antwoorden bent gekomen.
  • Leg uit. Vertel de klant waarom je juist die vragen hebt gesteld en wat je niet getest hebt. Wat zijn de prio’s en risico’s. Hoe heb je vastgesteld dat de software werkt?
  • Betrek de mensen. Werk vanuit een Whole Team Approach en stel vragen over wat je omgeving (of team, of stakeholders) nog wil weten van het systeem.
  • Communiceer. Niet alleen over je keuzes, bevindingen en gevoel. Maar ook over de verwachtingen, ideeën en het gevoel van de mensen om je heen.

Conclusie

Terugkomend op de vragen uit de inleiding, dan kunnen we daar nu een antwoord op geven. Want hoe toon je kwaliteit aan? Door de juiste vragen te stellen en deze te beantwoorden. Hoe creëren we vertrouwen in het testproces en het systeem? Door goed te communiceren over de gestelde en beantwoorde vragen en mensen hierbij te betrekken. Passen we (h)ET goed toe? Je past ET goed toe op het moment dat jij, je team en de organisatie vertrouwen hebben. Is dat het geval? Gefeliciteerd. Je bent een exploratory tester!

Wil je ons nieuwste Paarsz magazine per post ontvangen? Laat dan je gegevens achter.

Ontwerp zonder titel (19)

Werken bij Bartosz?

Vincent Verhelst

Geïnteresseerd in Bartosz? Dan ga ik graag met jou in gesprek. We kunnen elkaar ontmoeten met een kop koffie bij ons op kantoor. Of tijdens ontbijt, lunch, borrel of diner op een plek die jou het beste uitkomt. Jij mag het zeggen.

Mijn Paarsz