De eeuwige vraag in software testen: wanneer is er genoeg getest?
In de wereld van software testen is er een vraag die constant terugkomt: wanneer is er genoeg getest? Deze vraag is van cruciaal belang voor iedereen die betrokken is bij het ontwikkelen van kwalitatief hoogwaardige software, van testers en ontwikkelaars tot projectmanagers en stakeholders. Het bepalen van de juiste hoeveelheid testen is een lastige afweging die afhangt van verschillende factoren, waarvan er een aantal in dit artikel worden uitgelegd.
De 2 bekende valkuilen
Om te beginnen is het essentieel om te begrijpen wat ‘voldoende’ testen in een specifieke situatie betekent. Er is geen universeel antwoord. Er zijn wel twee veelvoorkomende valkuilen aan de uiteinden van het spectrum: door deadlines en druk kan de neiging ontstaan om hoeken af te snijden en te weinig te testen, dit kan leiden tot het missen van kritieke bugs. Aan de andere kant zal het streven naar het testen van elk mogelijk scenario leiden tot een onhaalbare en overweldigende hoeveelheid werk.
Het vinden van de juiste balans is cruciaal. Daarbij moet worden gestreefd naar grondige verkenning van kernfuncties en een redelijke dekking van secundaire functies. Overleg met stakeholders en het projectteam om te bepalen welke functies de hoogste prioriteit hebben. Kernfuncties vereisen grondige en uitgebreide testen om er zeker van te zijn dat ze robuust en betrouwbaar zijn. En secundaire functies moet je testen om te zorgen dat ze werken zoals bedoeld, maar je hoeft niet elk mogelijk scenario of elk randgeval te testen.
Testdekking
Testdekking is een essentiële maatstaf om te bepalen of testers alles testen wat ze zouden moeten testen. Het helpt bij het identificeren van hiaten in de testsuite en het verbeteren van de algehele kwaliteit.
Er bestaan verschillende testdekkingstechnieken, denk bijvoorbeeld aan deze:
Productdekking: Omvat alle aspecten van het product, inclusief functionaliteit, gebruikersinterface, gebruikerservaring en compatibiliteit.
Productdekking: Omvat alle aspecten van het product, inclusief functionaliteit, gebruikersinterface, gebruikerservaring en compatibiliteit.- Vereistendekking: Zorgt ervoor dat de applicatie voldoet aan de vastgestelde requirements, zelfs als de basisfuncties naar behoren werken.
- Risicodekking: Richt zich op het testen van de risico’s die aan een applicatie zijn verbonden, om de impact van mogelijke fouten te minimaliseren
De keuze voor een specifieke testdekkingsmethode, of een combinatie van meerdere, hangt af van de specifieke context van het softwareproject. Er is geen one-size-fits-all oplossing. Het is belangrijk om de voor- en nadelen van elke methode te begrijpen en een weloverwogen beslissing te nemen op basis van de risico’s, prioriteiten en doelstellingen van het project.
Welke testmethode kies je?
De keuze van de testmethode bepaalt ook voor een groot deel hoe ‘klaar’ gedefinieerd wordt. De gebruikte testmethode bepaalt hoe je de dekking (test coverage) meet en wat je als ‘voldoende’ beschouwt. Elke methode heeft een andere manier om te bepalen wanneer je kunt stoppen met testen. Hieronder 3 voorbeelden:
Bijvoorbeeld bij risicogebaseerde testen richt je je op de delen van de software waar de kans op fouten of het risico van falen het grootst is. Je stopt met testen als het risico voldoende is verlaagd. Dit is subjectiever dan bij andere methoden. Je kunt beslissen om te stoppen als er geen ernstige defecten meer worden gevonden in de risicovolle delen.
En omdat je je richt op risico’s, is er geen harde ‘dekkingsdoelstelling’. Je moet een inschatting maken van wat een acceptabel risico is. Het moment van stoppen is hier veel moeilijker te bepalen.
Bij structuurgebaseerde methoden (bijv. whitebox testen, zoals code coverage of loop- of path testing) test je op basis van de interne structuur van de software. Je kunt meten hoeveel procent van de code is uitgevoerd (zoals lijn- of takdekking). Als je bijvoorbeeld 80% dekking als doel stelt, weet je dat je kunt stoppen met testen zodra je dat doel hebt bereikt. Hoge dekking betekent in dit geval dus niet altijd dat er geen fouten meer zijn, vooral niet als je bepaalde logica over het hoofd ziet.
Bij exploratory testing test je zonder vooraf gedefinieerde testgevallen. De tester gebruikt zijn ervaring en intuïtie om fouten te vinden. Omdat er geen vooraf gedefinieerd dekkingsdoel is, wordt vaak gekeken naar het aantal nieuwe fouten dat wordt gevonden. Als het aantal nieuwe fouten afneemt, wordt dat vaak gezien als een teken dat het voldoende is. Je kunt zeggen dat je genoeg hebt getest als je gedurende een bepaalde tijd geen nieuwe fouten meer vindt. Maar er is hier geen harde grens, omdat het subjectief blijft.
Communicatie en stakeholderbetrokkenheid
Het is cruciaal om te onthouden dat de uiteindelijke beslissing over ‘voldoende’ testen bij de stakeholders ligt. Als tester is het jouw verantwoordelijkheid om hen te voorzien van de informatie die ze nodig hebben om een weloverwogen beslissing te nemen.
Twee belangrijke tips voor testers in dit kader zijn de volgende:
- Communiceer in de taal van risico: In plaats van te praten in technische termen, presenteer je testinspanningen in termen van risico’s en voordelen. Dit zal de aandacht van het management trekken en leiden tot betere besluitvorming.
- Onderhandel over scope, niet over inspanning: Wanneer budgetten beperkt zijn, is het belangrijk om te onderhandelen over de scope van de tests in plaats van over de benodigde inspanning.
Samengevat
De vraag ‘wanneer is er genoeg getest?’ heeft geen eenvoudig antwoord. Het vereist een zorgvuldige afweging van verschillende factoren, waaronder de context van de software, de risico’s, de bedrijfsdoelen en de input van stakeholders. Door een evenwichtige teststrategie te hanteren, testdekkingstechnieken te gebruiken en effectief te communiceren met stakeholders, kunnen testers ervoor zorgen dat softwareproducten grondig worden getest en voldoen aan de kwaliteitsverwachtingen.
Korte checklist
Ondanks het feit dat er geen universeel antwoord is op de vraag wanneer je klaar bent met testen, zijn er wél duidelijke signalen dat je op het juiste moment kunt stoppen. Als je de volgende vragen met ‘ja’ kunt beantwoorden, is het waarschijnlijk tijd om het testen af te ronden:
Heb je de kernfunctionaliteiten getest en werken ze zoals verwacht?
Heb je de kernfunctionaliteiten getest en werken ze zoals verwacht?- Zijn de belangrijke risico’s geïdentificeerd en aangepakt?
- Heb je testdekkingstechnieken toegepast (zoals vereistendekking, productdekking of risicodekking)?
- Zijn de stakeholders het eens met het testniveau en de resterende risico’s?
Wanneer je al deze vragen met ‘ja’ kunt beantwoorden, kun je met vertrouwen concluderen dat je voldoende hebt getest. Uiteraard blijft het een afweging van risico’s, prioriteiten en beschikbare tijd, maar met een gestructureerde aanpak voorkom je onnodig testen en zorg je voor een optimale testinspanning.