Het vakidioom

Testers en mensen van de business begrijpen elkaar vaak niet. Stel de volgende situatie voor: een testmanager staat aan het begin van zijn project en wil gestructureerd zijn project gaan uitvoeren. Een van de zaken die de testmanager nodig heeft is een teststrategie. Om de strategie te kunnen bepalen belegt hij een workshop met zijn stakeholders. Om goed beslagen ten ijs te komen heeft de testmanager zich tot in detail voorbereid. Vragenlijsten zijn opgesteld, beschikbare documentatie is grondig doorgelezen, met een aantal applicatiebeheerders is uitgebreid gesproken. Kortom het kan gewoon niet mis gaan!

Vol goede moed begint hij met de workshop. De eerste vraag wordt aan de opdrachtgever gesteld: Wat moet er van het kwaliteitsattribuut leerbaarheid getest worden voor module A? “Zullen we de rekenmodule syntactisch testen?” is een vraag die de accountant gesteld krijgt.

De stakeholders kijken elkaar niet begrijpend aan en zijn direct het spoor volledig bijster. Ze proberen zich een beeld te vormen van de vragen en geven zo goed en kwaad als het kan een antwoord. De testmanager is verbaasd over het antwoord en snapt op zijn beurt het antwoord niet. De vragen zijn toch duidelijk? Waarom een dergelijk vaag of ontwijkend antwoord? Zo sleept de workshop zich voort. Na twee uur beëindigt de testmanager de workshop. De stakeholders gaan weg met een slecht gevoel. Wat was nu het doel van deze exercitie? Wat voor soort systeem krijg ik dadelijk? Dit slechte gevoel zal weinig vertrouwen geven. De testmanager zit met hetzelfde gevoel. De input van de stakeholders is onduidelijk, waardoor de testdoelen onduidelijk zijn, of gebleven. Kortom een en al onduidelijkheid. Wordt hier een uitzonderlijke situatie geschetst? Helaas niet. In mijn rol als testadviseur kom ik het regelmatig tegen. Wat is de oorzaak van deze problematiek?

Ieder beroep heeft zijn eigen taal. De timmerman praat over: “We zagen er even een plankje in”. Hij bedoelt dan: we hangen de schappen van de kast even op! Zo ook wij als testers. Iedereen weet dat ons vak de laatste jaren zich enorm heeft ontwikkeld. Daarbij is ook het aantal begrippen en termen toegenomen. Bij ieder seminar worden er nieuwe begrippen geïntroduceerd door de geachte sprekers. Bovendien kan de betekenis van een bestaand begrip verschuiven. Daar ligt de oorzaak van het probleem van onze testmanager. We zijn met zijn allen zo bezig om te laten zien dat we ons vak beheersen dat we de klanten, waarvoor we het allemaal doen, vergeten. Onze stakeholders begrijpen kreten als ‘leerbaarheid’ en ‘het syntactisch testen van een rekenmodule’ niet. De stakeholders denken in termen als debet en credit. Als testers moeten we in staat zijn om de taal van onze gesprekspartner te begrijpen en te leren spreken. De informatie die aldus verkregen wordt kan dan door ons vertaald worden naar ons eigen vakjargon. Dit vertalen van jargon naar de taal van de klant en omgekeerd geldt niet alleen voor onze ongelukkige testmanager maar voor iedere rol die in het vakgebied wordt onderscheiden.

Op het moment dat je in staat bent te denken in de wereld van de stakeholder zal de hiervoor genoemde workshop veel meer resultaat opleveren. De doelen die bereikt moeten worden zijn helder en scherp uitgekristalliseerd.

Bereik je dit zomaar? Het antwoord is nee. Als tester moet je er aan werken om je deze vaardigheden eigen te maken en daardoor je (test)bagage nog verder te vergroten. De vraag is natuurlijk hoe je leert denken in de taal van de stakeholder. Het staat buiten kijf dat je in een aantal gevallen nooit het gedetailleerde niveau van de stakeholder kunt en moet willen bereiken. Maar wat dan? Hier volgen een aantal handvaten.

Het klinkt als een open deur, maar verdiep je bijvoorbeeld voor het opstellen van de teststrategie in de bedrijfstak, klant en project. Probeer te achterhalen wat de bedrijfsdoelstellingen zijn. Waarom moet het project worden uitgevoerd? Wat draagt het project bij aan de bedrijfsdoelstellingen. Je krijgt dan een idee van wat er getest zou moeten worden. In het voorbeeld werd leerbaarheid genoemd. Indien je de indruk krijgt dat leerbaarheid een testonderwerp is, moet je voor jezelf vragen definiëren. Hierdoor kun je er voor jezelf achter komen of leerbaarheid echt wel zo belangrijk is dat er aandacht aan moet worden besteed. Voorbeelden van vragen zijn: welk type gebruiker gaat het systeem gebruiken? Is het een nieuw systeem? Wat zijn de specifieke kenmerken van het systeem? Dit zijn voorbeelden van vragen waarmee achterhaald kan worden of leerbaarheid een testonderwerp is. Inmiddels zijn er verschillende tools en checklists beschikbaar die de testmanager kunnen ondersteunen bij het proces van bepalen wat nu wel en wat niet van belang is.

Een andere mogelijkheid is het uitbreiden van de aanwezige basiskennis door het volgen van specifieke branchecursussen. Voor verschillende branches zijn cursussen beschikbaar waarmee in redelijke korte tijd een goed inzicht verkregen kan worden in de bedrijfstakspecifieke materie. Met behulp van deze kennis kan de testmanager dan een complete en efficiënte teststrategie ontwikkelen.
Compleet in de zin van met kennis van zaken in de bedrijfstak en efficiënt in termen van kort, krachtig en de juiste focus in testen aangebracht.

Zo blijkt dat de testmanager kennis nodig heeft van verschillende gebieden. Niet alleen testkennis, maar ook van sociale vaardigheden, ict-kennis en materiekennis. Op het moment dat de testmanager in staat is te schakelen tussen de materie en de vakinhoudelijke testkennis, dan functioneert de testmanager echt als een bruggenbouwer tussen de business en het testteam en zullen de resultaten van het testproject verbeteren en beter geaccepteerd worden.