Leiderschap bij het testen: hoeveel testen is genoeg?
Noot van de redactie: Welkom bij de serie Leiderschap in testen van softwaretestgoeroe en consultant Paul Gerrard. De serie is bedoeld om testers met enkele jaren ervaring—vooral degenen in agileteams—te helpen uitblinken in hun rollen als testleider en manager.
In het vorige artikel schetsten we een risicomanifest om managers te helpen. In dit artikel stellen we de eeuwenoude vraag: “Hoeveel testen is genoeg?”. Vooruitblik: dat hangt af van de belanghebbenden.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te krijgen wanneer nieuwe delen van de serie online komen. Deze posts zijn fragmenten uit Pauls cursus Leiderschap in testen, die we ten zeerste aanbevelen voor een diepere duik in dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER voor $60 korting op de volledige cursusprijs!
Hoeveel testen is genoeg? Dit is de klassieke, onbeantwoordbare, filosofische vraag die alle testers stellen, omdat hun belanghebbenden die vraag aan hen stellen.
Belanghebbenden willen dit weten omdat ze er vertrouwen in willen hebben dat systemen afdoende zijn getest, maar omdat zij ervoor betalen en deadlines moeten halen, willen ze ook weten wat de mogelijke kosten van het testen zijn en hoelang het zal duren.
Daarom is het aan de belanghebbenden om te beoordelen hoeveel testen genoeg is. Jouw taak als testmanager is om hun zoveel mogelijk waarde te bieden door hen te helpen een beslissing te nemen. In dit artikel behandelen we:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- De waarde van testen voor belanghebbenden
- Kwantumtheorie en de relativiteitstheorie (niet de natuurkunde)
- De juiste taal gebruiken
- Schattingen, budgetten en onderhandelingen
Laten we beginnen.
De waarde van testen voor belanghebbenden
Elke test die we uitvoeren, moet waarde hebben voor belanghebbenden, doordat deze bewijs levert ter ondersteuning van hun besluitvorming op vier manieren:
- Bewijs dat het systeem de bedrijfsdoelstellingen van het project zal behalen.
- Bewijs dat het systeem niet zal falen, of dat, als het wel faalt, de gevolgen van de fout te dragen zijn.
- Bewijs om fouten te reproduceren en diagnosticeren en het defecte systeem te herstellen en opnieuw te testen.
- Bewijs ter ondersteuning van besluitvorming in de context van een project (accepteren, vrijgeven, afwijzen enzovoort).
Ons doel bij het testen is om tests te creëren die de testdekking van het systeem stapsgewijs vergroten met betrekking tot een herkenbaar testmodel. Onze tests moeten aantonen dat het systeem de bedrijfsdoelstellingen zal behalen en dat het risico op een fout bekend en hopelijk aanvaardbaar is.
Van de vier bovenstaande soorten bewijs vormen de eerste drie de basis voor de vierde. Uiteindelijk moeten de belanghebbenden een op bewijs gebaseerde beslissing nemen. Het is hun beslissing om te nemen, niet die van de testers, dus zij moeten beoordelen of ze genoeg informatie hebben om vertrouwen te voelen. Hoe dan ook, de waarde van testen ligt in het oog van de belanghebbende.
Elke tester maakt keuzes over wat er getest moet worden door een formeel model te gebruiken of zelfs op zijn onderbuikgevoel af te gaan. Deze keuzes worden gemaakt op basis van een bepaalde ingeschatte waarde.
Tenzij de tester ook de belanghebbende is, beoordeelt de tester waarde doorgaans op basis van een bepaalde maatstaf voor volledigheid of dekking. Of, als de tester inzicht heeft in de gedachten van de belanghebbenden, op basis van de vraag of de test een bepaalde acceptatiebeslissing zal ondersteunen.
De bovenstaande uitgangspunten hebben enkele belangrijke gevolgen.
Ten eerste: als je niet weet wat de belanghebbende belangrijk vindt, zal jouw perceptie van testwaarde waarschijnlijk niet dezelfde zijn als die van hen. Als je tests selecteert zonder rekening te houden met hun waarden, kunnen je belanghebbenden op het moment dat je je resultaten presenteert, ontdekken dat ze op sommige gebieden onvoldoende gegevens hebben en op andere gebieden een overschot aan gegevens. Ze zullen zich zeker niet zo zelfverzekerd voelen als zou moeten.
Ten tweede: wat is de bijdrage van een test aan de besluitvorming van de belanghebbende wanneer je die ontwerpt of uitvoert? Als een test geen incrementele informatie oplevert ter ondersteuning van een beslissing, of als het belanghebbenden niet uitmaakt of je test slaagt of faalt, dan hoort die test niet thuis in een testplan.
We zeiden in artikel 3 over modellen dat de testmodellen die je gebruikt relevant moeten zijn voor belanghebbenden. Als je testresultaten aansluiten op modellen die de belanghebbenden begrijpen en waardevol vinden, zullen zij jouw bijdrage waarderen.
Kwantumtheorie en de relativiteitstheorie
Er zijn nog twee principes die verband houden met de waarde en betekenis van tests. Ik noem het ene de kwantumtheorie en het andere de relativiteitstheorie. Deze benamingen klinken pretentieus (ze zijn zeker met een knipoog bedoeld), maar ze beschrijven twee fenomenen die ten grondslag liggen aan alle discussies over testwaarde, prioritering en afbakening.
Wanneer we een test uitvoeren, interpreteren we de uitkomst meestal als geslaagd of mislukt. Het oordeel geslaagd/mislukt is een binaire uitkomst: waar of onwaar, ja of nee, een één of een nul. Die testuitkomst genereert een discrete hoeveelheid bewijs. Bewijs stapelt zich op naarmate we steeds meer tests uitvoeren. Wat de uitkomst ook is, die test vergroot stapsgewijs de dekking van ons testmodel en onze kennis van het gedrag van het systeem. Tests die niets aan onze kennis toevoegen, voegen geen waarde toe.
Als een test de dekking op geen enkele manier stapsgewijs vergroot, heeft deze weinig waarde.
Het tweede aspect is de waarde van een test. Wat is de waarde van een test? Kun je werkelijk een dollar-, pond- of eurobedrag aan één test toekennen? Waarschijnlijk niet. Maar wat we wel kunnen doen – en vaak vrij eenvoudig – is zeggen: ‘deze test is waardevoller dan die andere’.
Stel dat we een model voor codedekking gebruiken, zoals instructiedekking. We kunnen een test uitvoeren die vijf regels code of vijfduizend regels code uitvoert. Wat is de waarde van elk daarvan? Dat is moeilijk te zeggen. Maar als ons doel instructiedekking is, heeft de tweede test meer waarde.
We kunnen geen absolute waarde aan een test toekennen, maar meestal kunnen we tests wel vergelijken en de relatieve waarde van elk ervan afleiden. Dat wil zeggen: als we onder tijdsdruk staan, kunnen we meestal zeggen dat de ene test minder waarde heeft dan de andere en daarom de eerste test buiten de reikwijdte laten als dat nodig is.
We kunnen de waarde van tests vergelijken, maar alleen als ze van hetzelfde model zijn afgeleid.
We moeten echter benadrukken dat deze vergelijkingen alleen echt betekenisvol zijn als ze hetzelfde model delen. Een test die een groot aantal extreme omstandigheden in een proces afdekt, heeft waarschijnlijk meer waarde dan een test van het ‘rechttoe-rechtaan’-pad. Tests van begin tot eind van een complex proces kunnen bijvoorbeeld niet rechtstreeks worden vergeleken met de unittests van kritieke componenten.
Hoewel de theorieën van de kwantummechanica en de relativiteit misschien niet rechtstreeks van toepassing zijn op testen, zijn de principes van aanpasbaarheid en perspectief dat wel. Zoek een testmanagementtool die aansluit bij deze principes om je teststrategie te optimaliseren.
De juiste taal gebruiken
Nu we hebben vastgesteld wie verantwoordelijk is voor het bepalen van ‘hoeveel testen genoeg is’, hoe kunnen wij als gewetensvolle testers deze besluitvorming ondersteunen?
Merk op dat onze behandeling van de waarde van tests sterk lijkt op onze beoordeling van risico’s. Zoals in het vorige artikel besproken, is het erg moeilijk om numerieke waarden toe te kennen aan de omvang of blootstelling aan risico’s. Het is echter meestal wel mogelijk om het ene risico met het andere te vergelijken en ze te rangschikken, zodat keuzes kunnen worden gemaakt over de risico’s die binnen de reikwijdte van het testen vallen.
Door de taal van risico’s te gebruiken, zullen testers door het management worden gehoord.
Teamleiders van ontwikkeling lijken vaak door managers te worden gehoord, zelfs wanneer ze in technische termen praten. Het verschil is dat zij technologie presenteren als iets spannends en voordeligs. Wanneer testers in hun eigen technische termen praten – over de ‘administratieve’ details van tests, zoals incidentstatistieken – is de boodschap vaak negatief en kunnen managers zich gaan vervelen of geïrriteerd raken.
Het management denkt misschien al dat testers als soort een beetje saai zijn, maar dat komt waarschijnlijk doordat veel managers niet echt begrijpen wat testers doen en welke waarde zij toevoegen. Testers moeten hun taalgebruik daarom naar het niveau van het management tillen.
Risicogebaseerd testen spreekt gebruikersmanagement en projectmanagement aan in hun eigen taal.
Dit zijn mensen die sterk denken in termen van risico’s en voordelen. Als testers hen in vergelijkbare termen aanspreken, is de kans groter dat het management naar hen luistert en daardoor betere beslissingen neemt. Door tests te relateren aan de doelen van het project, kunnen we de aandacht richten op de resultaten die voor belanghebbenden de meeste waarde hebben, zodat we onze tijd besteden aan het testen van de belangrijkste zaken.
Naarmate er verder wordt getest, kunnen we bovendien aantonen dat de waardevolste voordelen nu beschikbaar zijn. De beslissing om uit te brengen is uiteindelijk een oordeel over de vraag of de behaalde voordelen opwegen tegen de risico’s. Testen levert het management dus betere gegevens op om beslissingen op te baseren.
Gebruik de taal van risico’s (en voordelen) om het testen af te bakenen, te plannen en de voortgang ervan te rapporteren.
Testers moeten uiteraard technisch kunnen overleggen met ontwikkelaars en andere technische medewerkers. Zo is de kwaliteit van incidentrapporten een belangrijke factor om fouten snel en betrouwbaar te laten corrigeren. Ik zeg alleen dat de tester bij gesprekken met het management spreekt in termen van aangepakte en nog openstaande risico’s, in plaats van tests, incidenten en fouten.
Schattingen, budgetten en onderhandelingen
Al vroeg in een nieuw project vraagt je projectmanager je: “Ik moet de planning en bezetting van het testen tijdig regelen. Kun je me een schatting geven van hoeveel mensen je nodig hebt en hoe lang je nodig hebt om het systeem te testen?”
Je denkt er even over na en gaat met de baas praten.
“Ik heb zes testers nodig voor acht weken.”
De projectmanager denkt even na en raadpleegt zijn conceptplanning en resourceplan.
“Je kunt vier testers krijgen voor zes weken, meer niet.”
Je maakt bezwaar en zegt: “Maar het duurt langer dan zes weken! Het kost meer dan je hebt toegewezen voor het testen van dit systeem. Het systeem is groter dan de vorige keer. Het is ingewikkelder. Het is zeker te riskant om deze keer op het testen te bezuinigen. Het is gewoon niet genoeg.”
Maar de manager blijft bij zijn standpunt en mompelt iets over andere afhankelijkheden, hogere instanties enzovoort…
Wat denk je dat het nut was van een schatting maken als de manager al die tijd wist wat het budget moest zijn? Welke relevantie heeft een willekeurig budget voor het werk dat moet worden uitgevoerd? Waarom nemen ze testen nooit serieus? De ontwikkelaars krijgen toch altijd de tijd waar ze om vragen? Het lijkt niet eerlijk.
Je kunt je benadeeld voelen en het idee hebben dat je professionele oordeel wordt ondermijnd. Maar het probleem is, en is altijd geweest, dat het testbudget in deze situatie vaststond. Het enige wat je kunt doen, is bepalen welke tests je binnen je budget het beste of meest waardevol kunt uitvoeren.
Maar vaak wil de projectmanager echt weten hoe lang iets gaat duren, zodat het plan kan worden aangepast. Als je denkt dat je aan het onderhandelen bent, heb je enkele ruilmiddelen nodig. Je moet ook de resultaten van het plan bespreken, niet de invoer. De reikwijdte is een resultaat van de planning; de inspanning die je levert, is een invoer.
Je moet over de reikwijdte onderhandelen.
Bij onderhandelingen over testbudgetten moet het altijd gaan over de reikwijdte, niet over de inspanning.
De reikwijdte kan in een of meerdere vormen worden vastgelegd. De manier waarop je de reikwijdte presenteert en bespreekt, zal variëren, maar hier volgen enkele veelvoorkomende patronen. Welke reikwijdte je ook hebt, je gebruikt die als basis voor je schatting en de onderbouwing ervan:
Reikwijdte als een inventaris van vereisten of functies
Als de schatting met 30% wordt verlaagd, vraag dan: “Welke 30% van het systeem moet ik niet testen?”
Reikwijdte als een inventaris van risico’s
Als de schatting met 30% wordt verlaagd, vraag dan: “Welke risico’s voor belanghebbenden moeten we uit het plan schrappen?”
Reikwijdte als een tabelvormig of grafisch model
Als de schatting met 30% wordt verlaagd, vraag dan: “Welke paden/reizen/onderdelen moet ik de belanghebbenden vertellen dat niet getest zullen worden?”
Ik hoop dat je ziet wat hier gebeurt.
- De reikwijdte van het testen is gebaseerd op een model dat eerst met de belanghebbenden is besproken en overeengekomen. Deze reikwijdte is voorlopig, afhankelijk van de beschikbaarheid van middelen en tijd, en je moet de belanghebbenden daarvan bewust maken.
- Je maakt een schatting op basis van die voorlopige reikwijdte. Gebruik het model (risico’s, vereisten, bedrijfsproces of een ander model) om een dekkingsdoel vast te stellen, tel de dekkingsitems en maak op basis daarvan een schatting.
- Bespreek dit met de projectmanager. Als de schatting te hoog is, gebruik dan de bovenstaande antwoorden om de gesprekken met de belanghebbenden op gang te brengen.
Als tester of testmanager bevind je je niet in een goede positie om met de projectmanager over testen te onderhandelen. Belanghebbenden hebben de zorgen en als je de modellen deelt die de testreikwijdte bepalen, zullen zij een mening hebben, instemmen met de reikwijdte en deze kunnen verdedigen. Belanghebbenden zijn ook verantwoordelijk voor het rechtvaardigen van het budget voor hun systeem. Daarom zijn zij het best geplaatst om de kosten van het testen af te wegen tegen de noodzaak om hun zorgen aan te pakken.
Stof tot nadenken
Denk eens na over wie in jouw projecten verantwoordelijkheid neemt voor de hoeveelheid testen die moet worden uitgevoerd:
- Bepaal jij als tester de reikwijdte en de hoeveelheid testen?
- Stelt de projectmanager een budget vast en doe jij wat je kunt met de tijd die je krijgt toegewezen?
- Wordt de reikwijdte onderhandeld met de projectmanager en belanghebbenden om overeenstemming te bereiken over een balans tussen inspanning en de uit te voeren testreikwijdte?
Een van de belangrijkste verantwoordelijkheden van een tester is ervoor te zorgen dat het project zich bewust is van de productrisico’s die worden genomen en deze te documenteren. Alleen als deze risico’s zichtbaar zijn, kan het management de risico’s herkennen die het neemt door het testen te beperken.
Er bestaat geen formule voor de juiste hoeveelheid testen. In de meeste omgevingen kan het testniveau alleen worden bepaald door consensus tussen projectmanagement, klantsponsors, ontwikkelaars, technische specialisten en testers – tests vallen binnen de reikwijdte als ze de risico’s aanpakken waarover men zich zorgen maakt.
Voldoende testen moet door consensus worden bepaald, waarbij de tester het consensusproces faciliteert en informatie eraan bijdraagt.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te krijgen wanneer nieuwe delen van de reeks online komen. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen, die we ten zeerste aanbevelen voor een diepgaandere behandeling van dit en andere onderwerpen. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER voor $60 korting op de volledige cursusprijs!
Gerelateerde artikelen:
