De klant centraal

Stel je voor dat een klant je vraagt wat je als tester nou eigenlijk doet. Chances are dat je niet veel verder komt dan ‘instaan voor de kwaliteit’ of ‘fouten vinden’. Mocht je jezelf toch verleiden om de ins en outs van testen uit te leggen, dan zie je dezelfde klant vaak binnen een paar minuten afhaken.

Misschien uit desinteresse, misschien vanwege de uitleg die al snel alleen gevolgd kan worden door andere testers.

Als externe softwaretesters worden we ingehuurd omdat een opdrachtgever een hoop geld over heeft om de kwaliteit van een product naar een op zijn minst voldoende niveau te tillen. En vaak gebruiken we een lastig verhaal over onze waarde, dat bovendien moeilijk aansluit bij de klantbeleving.

Laten we dat veranderen.

 

Drie werelden, drie bruggen

Stel jezelf drie werelden voor:

• De eerste wereld is de klant, en al zijn uitgesproken, vanzelfsprekende en onbewuste wensen.
• De tweede wereld is de blauwdruk (de specifications, de requirements, user stories, systeemtekeningen, enfin, alles) waar je je checks op baseert.
• De derde wereld is het te testen product.

 

Deze werelden leven niet los van elkaar, maar zijn verbonden door drie bruggen.

• Brug nummer één is de brug tussen de klant en de blauwdruk. Hier zal een designer druk zijn, want deze moet de wensen van de klant in kaart brengen. Hier is een tester óók druk: risico-analyse, user stories onderzoeken, horrorplots maken, wellicht meedoen aan een three amigo sessie, kortom: is het verhaal van de designerconsistent en volledig, en wat wil de klant dat er allemaal niet gebeurt?
• Brug nummer twee is de brug tussen de blauwdruk en het daadwerkelijke product. Hier is de developer druk met bouwen, maar ook de tester heeft het druk: je voert handmatig of geautomatiseerd scripts uit en checkt of dat wat is afgesproken ook daadwerkelijk wordt gerealiseerd.
• Brug nummer drie is de brug tussen het product en de klant. Hier plaats je activiteiten als exploratory testing (hoe gedraagt de nieuwbouw zich in de reeds bestaande context) en bughunts (de klant confronteren met de nieuwbouw, waar weer wensen uit komen).

Op deze drie bruggen wordt tenslotte vanzelfsprekend gebruikt gemaakt van alle communicatieve middelen die we als testers voor handen hebben: vragen stellen, feedback geven, onderhandelen, rapporteren, enz..

Een en ander is samen te vatten in het volgende figuur:

 

Verhaal

Als ik morgen door een willekeurige klant gevraagd zou worden wat een softwaretester eigenlijk doet, dan zou op basis van bovenstaand model dít mijn verhaal zijn:

“Een tester wordt betaald om de kwaliteit van het in aanbouw zijnde product naar een voldoende niveau te trekken. Kwaliteit betekent alle kenmerken en eigenschappen van een product die betrekking hebben op jouw impliciete en expliciete wensen ten aanzien van dat product. Anders gezegd: hoe dichter die kenmerken en eigenschappen aansluiten bij jouw wensen, hoe hoger de kwaliteit, en hoe tevredener jij dus bent.

Hoe doet de tester dat dan? Door die activiteiten uit te voeren die betrekking hebben op de bruggen tussen jou, de specificaties en het daadwerkelijke product.
De tester zorgt door middel van bijvoorbeeld een analyse op de user stories er mede voor dat het bouwteam een eenduidig en volledig beeld krijgt van wat jij wilt.

Vervolgens vergelijkt de tester die user stories met het in aanbouw zijnde product, zodat we weten dat dát wat jij wenst ook daadwerkelijk gebouwd wordt, en fouten worden opgespoord en verwijderd.

Tenslotte test de tester het product in een breder verband, zodat deze het ook doet in de boze buitenwereld, én als bonus dat behoeftes waar jij je nog niet bewust van was boven tafel komen.

En dat allemaal zodat jij vertrouwen krijgt in het product dat het team aan het maken is.”

Klaar.

 

Meer voordelen

Deze plaat helpt je niet alleen om de klant duidelijk te maken wat je doet, hoe je dat doet en waarom. Naast uitleg over het belang van je werk stelt het je ook in staat om eens na te denken wat er nog meer aan activiteiten bruikbaar zouden zijn: welke testactiviteiten staan er nu nog niet op de bruggen? Wat missen we?
Daarnaast kun je dit model ook gebruiken om andere spelers in het veld centraal te stellen:

• Wat als je bijvoorbeeld je eigen behoeftes als tester centraal stelt, in plaats van die van de klant? “Testplan” invult waar hierboven nog ‘requirements’ staat, en “testproces” waar nu nog “product” staat?
• Wat zou een teamgenoot (een designer of developer) gaan roepen als haar of zijn rol, plan en werkuitvoer centraal zou staan?

 

Afsluitend

Als we de modellen bekijken die in het vorige millennium zijn gemaakt, dan valt het me op dat met name het testwerk centraal staat: testtechnieken pontificaal in het midden, of modellen die daar alléén maar om draaien. Logisch misschien vanuit een waterval perspectief: het product was immers al ‘klaar’, en in het gehele watervalmodel was er een vaste fase waarbinnen de tester kon ‘shinen’.

Die tijden zijn echter voorbij. Laten we de tester gaan positioneren zoals nu de bedoeling is: als een service-verstrekker aan de klant en lid van een team waarvan alle leden op deze drie bruggen hun diensten aan de klant verlenen.

 

Ik, Bas Kruip, hoor graag jullie mening ten opzichte van de drie bruggen, het model en de visie!

Naar het overzicht