MARCH 24, 2026 – FREE WEBIBAR: Future-Proofing SAP Cloud with AI & Automation
Het is een van de meest gestelde, maar tegelijkertijd ook een van de moeilijkste vragen binnen de softwareontwikkeling: Wanneer stop je met testen? Vraag het aan een developer en het antwoord is vaak: “Als de code af is.” Vraag het aan een projectmanager (PM) en je hoort: “Wanneer de deadline is bereikt of het budget op is.” Maar vraag het aan een ervaren testmanager en het antwoord is steevast: “Wanneer het risico om live te gaan aanvaardbaar is.”
Het perfecte antwoord is niet zwart-wit. Software is in theorie namelijk nooit ‘100% af’ en je kunt onmogelijk elke denkbare combinatie van handelingen en systemen testen. In deze uitgebreide gids duiken we diep in de wereld van teststrategieën, exitcriteria en het managen van risico’s. Hoe bepaal je het kantelpunt waarop software klaar is voor productie? Wat zijn de best practices en wat te doen als de commerciële druk toeneemt?
De kernvraag achter “Wanneer stop je met testen?” is eigenlijk: Wanneer is mijn software klaar om naar productie te gaan? Als testmanager, QA-engineer of tester is het jouw taak om op een objectieve en transparante manier aan te tonen hoe de software er op een specifiek moment voorstaat. Stoppen met testen doe je wanneer je kunt bewijzen dat de applicatie grondig is onderzocht en dat de resterende risico’s minimaal en acceptabel zijn.
In de praktijk verloopt dit proces helaas niet altijd volgens het boekje. Veel testmanagers hebben situaties meegemaakt waarin een projectmanager simpelweg zegt: “We stoppen nu, want we gaan live.” Zonder dat daar een gegronde, kwalitatieve reden voor is. Dit soort beslissingen verhoogt het risico op kritieke fouten in productie aanzienlijk. Om dit te voorkomen, moet je aan het begin van elk project duidelijke afspraken maken: de zogenaamde exitcriteria.
Bij de opstart van een project stelt het QA-team een testplan of teststrategie op. Hierin worden de bekende vragen beantwoord:
Maar de belangrijkste vraag die vaak wordt vergeten, is: Wanneer stoppen we?
Het argument “We stoppen als het geld op is” of “als de deadline is bereikt” hoor je in de wandelgangen vaak. Hoewel budgetrestricties en deadlines de harde realiteit zijn van het bedrijfsleven, zijn het geen valide kwalitatieve exitcriteria. Als het budget op is, maar de core-functionaliteit crasht nog bij elke klik, dan is de software simpelweg niet klaar voor de eindgebruiker. Goede exitcriteria moeten gebaseerd zijn op meetbare kwaliteit.
Strategie 1: De status van defecten (Bug-triage)
Een van de meest gebruikte en effectieve exitcriteria is gebaseerd op de defectlijst (het bug-logboek). Tijdens het testen log je alle bevindingen in een defectmanagementsysteem (zoals Jira of Azure DevOps) en ken je prioriteiten toe: Critical, High, Medium, en Low.
Een solide exitcriterium is bijvoorbeeld:
“We stoppen met testen en gaan naar productie zodra alle ‘Critical’ en ‘High’ defecten volledig zijn opgelost én er voor eventuele openstaande ‘Medium’ defecten een door de business geaccepteerde workaround is.”
Strategie 2: Code Coverage (Whitebox-testing)
Een meer technische benadering is het meten van de dekkingsgraad via whitebox-testing. Hierbij draait er software op de achtergrond mee die meet welk percentage van de geschreven code daadwerkelijk door de tests is geraakt (code coverage of test coverage).
Kun je afspreken dat je stopt bij een code coverage van 100%? Dat hangt sterk af van het type applicatie. Voor kritieke medische software of systemen in de luchtvaart is een extreem hoge coverage vereist. Voor een gemiddelde bedrijfsapplicatie is 100% coverage vaak onbetaalbaar en onnodig; daar richt men zich eerder op een gezonde norm van bijvoorbeeld 80% tot 85%, gecombineerd met functionele tests.
Strategie 3: Requirements-dekking
Je kunt exitcriteria ook ophangen aan de functionele specificaties. Als je een lijst hebt met 50 requirements (eisen en wensen), en daar hangen 200 testscenario’s aan vast, dan kan het criterium zijn:
“We stoppen pas als 100% van de kritieke testscenario’s is uitgevoerd en succesvol (groen) is afgerond.”
De kunst is niet het bedenken van criteria, maar het kiezen van de juiste combinatie die past bij de context van jouw project.
Soms is de deadline zo hard dat de business geen keuze heeft. Denk bijvoorbeeld aan de historische overgang naar de Euro op 1 januari 2002 (of de voorbereidingen in de bankensector in de jaren direct daarvoor). Dat was een onherroepelijke deadline. De wet schreef voor dat systemen op die datum klaar moesten zijn. Of je testfase nu perfect was afgerond of niet: live gaan was verplicht.
Hoe ga je als testteam om met zulke extreme druk?
De paradox van software testing is dat je in feite nooit helemaal stopt. Als een applicatie eenmaal live staat (Go-Live), begint vaak direct de voorbereiding voor de volgende release. Dit brengt specifieke dynamieken met zich mee:
Regressietesten
Bij een tweede of derde release van software wil je er zeker van zijn dat de nieuwe functionaliteiten de bestaande, goed werkende onderdelen niet hebben stukgemaakt. Dit controleren we met Regressietesten. Dit kan handmatig, maar wordt idealiter (deels) geautomatiseerd om de snelheid erin te houden.
Post-Go-Live testen
Heb je vanwege een strakke deadline niet alles kunnen testen voor de livegang? Dan is het een absolute best practice om direct ná de Go-Live verder te testen in een stabiele omgeving. Je focust je op dat moment op de minst kritieke functionaliteiten die voorheen zijn blijven liggen. Doe je dat niet, dan worden de fouten vroeg of laat door de eindgebruiker in productie gevonden. En dat is een scenario dat je uiteraard wilt vermijden; een bug herstellen in productie is immers vele malen duurder dan in de testfase.
Het is de ultieme droomwereld van elke softwaretester: een onbeperkt budget en geen tijdsdruk. Hoe zou een testmanager het dán aanpakken?
Verrassend genoeg verandert de fundamentele teststrategie daardoor niet. Ook met miljarden op de bank blijft de basisstructuur overeind. Het grote voordeel is echter dat de druk van de ketel is. Je krijgt de ruimte om alles grondig aan te pakken. Je kunt de diepte in gaan met niet-kritieke functionaliteiten, uitgebreide performancetests draaien, security-audits uitvoeren en usability-onderzoeken doen met echte eindgebruikers. In de echte wereld is budget echter bijna altijd de limiterende factor, waardoor prioritering de belangrijkste vaardigheid van een tester blijft.
Exitcriteria in de praktijk: Het voorbeeld van een webshop
Om exitcriteria concreet te maken, kijken we naar een herkenbaar voorbeeld: een grote, bekende webshop. Wat zijn hier de absolute prioriteiten en hoe bepaal je wanneer je stopt met testen?
Bij een webshop draait alles om één hoofddoel: omzet genereren en artikelen verkopen. De core-functionaliteit bestaat uit een heldere trechter (funnel):
Dit zijn de vijf kritieke pijlers. Als je de exitcriteria voor de release van een webshop opstelt, focus je je volledig op deze keten. Werkt de koppeling met de bank (iDEAL, Bancontact, Creditcard) vlekkeloos? Kunnen orders correct worden verwerkt? Als dat honderd procent functioneert, is het acceptabel om live te gaan.
Futiliteiten, zoals een knopje dat net drie pixels naar links staat, een kleurafwijking in de footer, of een typefout in de algemene voorwaarden, zijn storend, maar ze verhinderen niet dat de webshop omzet draait. Dit zijn typische zaken die je op de defectlijst laat staan als ‘Low’ of ‘Medium’ en die pas na de livegang (of in een volgende sprint) worden opgelost.
Een andere, zeer wetenschappelijke manier om te bepalen wanneer je stopt met testen, is kijken naar de trendlijn van het aantal gevonden fouten: de defect-curve.
Wanneer een testteam start met een gloednieuwe release, zie je in de rapportages vrijwel altijd een sterke piek. Er worden in korte tijd heel veel bugs gevonden. Naarmate de ontwikkelaars deze bugs oplossen en het testteam hertesten uitvoert, vlakt de curve af. Er worden steeds minder nieuwe defecten ontdekt.
Als testmanager kun je besluiten: “We stoppen met testen zodra het aantal nieuw gevonden defecten per testdag onder een bepaald niveau zakt.” Op dat moment treedt namelijk de wet van de afnemende meeropbrengst in werking. De tijd, energie en het geld dat je moet investeren om nóg die ene kleine bug te vinden, is simpelweg groter dan de impact die die bug eventueel in productie zou hebben.
De testfase pauzeren: Aan de noodrem trekken
De defect-curve kan ook een alarmsignaal zijn. Soms zie je de curve niet dalen, maar juist exponentieel stijgen. Je logt één bug, de ontwikkelaar probeert het op te lossen, maar introduceert per ongeluk vier of vijf nieuwe fouten. Dit gebeurt vaak wanneer de code te complex is (spaghetti-code), de ontwikkelaars onder te hoge tijdsdruk staan, of wanneer zij de functionele context niet goed begrijpen.
Als testmanager moet je dan de moed hebben om te zeggen: “We pauzeren de testfase.” Continu testen tegen een muur van slechte kwaliteit is tijdsverspilling. Het demotiveert het testteam en kost onnodig veel geld aan administratie. Op zo’n moment ga je terug naar de tekentafel met het development-team om eerst de basisstabiliteit van de software op orde te krijgen.
Als we praten over bugs die door ontwikkelaars worden geïntroduceerd, moeten we ook kritisch kijken naar de fase daarvóór: de analyse. Want wanneer is een functionele of technische analyse volledig?
Fouten in software ontstaan vaak omdat de menselijke interactie aan het begin spaak loopt. Een analist luistert naar de wensen van de stakeholders, schrijft dit op in documentatie, en zowel development als QA moeten het daarmee doen. Als er in die documentatie al hiaten of foute aannames staan, bouwt de developer een ‘fout’ die eigenlijk precies volgens de specificaties is.
Hier komt het Shift Left-principe om de hoek kijken. Dit betekent dat het testteam al in een heel vroeg stadium, nog vóórdat er één regel code is geschreven, betrokken wordt bij het project. Door als tester de analyses kritisch te valideren op logische inconsistenties en onduidelijkheden, haal je de fouten eruit voordat ze geprogrammeerd worden. Dit bespaart enorm veel tijd in de latere testfase en zorgt ervoor dat je veel sneller je exitcriteria behaalt.
Wat als je als tester op een project komt waar geen documentatie, geen analyses en geen testgevallen klaarliggen? Ook dan kun je testen. Dit noemen we ad-hoc testing of exploratory testing. Je vraagt simpelweg aan een expert of eindgebruiker om het systeem intuïtief te gaan gebruiken en te kijken waar het breekt.
Hoewel dit een uitstekende methode is om snel een indruk te krijgen van de stabiliteit van een applicatie (bijvoorbeeld via een korte ‘smoke test’ of ‘free wheelen’ van een half uur bij een nieuwe dagelijkse build), mag ad-hoc testing nooit de basis zijn van je exitcriteria. Het is niet gedocumenteerd, niet herhaalbaar en biedt geen objectieve kwaliteitsgarantie.
Willen teams vandaag de dag sneller stoppen met testen dan vroeger?
Met de opkomst van Agile, Scrum, CI/CD (Continuous Integration/Continuous Delivery) en kortere releascycli (soms elke twee dagen of zelfs meerdere keren per dag live gaan), lijkt het alsof er minder tijd is om te testen. Maar willen teams ook sneller stoppen?
Nee, de drang naar kwaliteit blijft onveranderd. De context is echter gewijzigd door technologie. Dankzij moderne tools, Artificial Intelligence (AI) en vergaande testautomatisering ligt de snelheid van het testen tegenwoordig vele malen hoger dan vroeger. Maar de fundamentele wetten van QA blijven identiek: je moet nog steeds samen met de stakeholders om de tafel zitten, de risico’s inschatten en heldere exitcriteria definiëren.
Wanneer stop je dus met testen? Het antwoord is een optelsom van duidelijke afspraken en risicomanagement. Gebruik de volgende checklist om te bepalen of de testfase succesvol kan worden afgerond:
Testen is geen doel op zich, het is een middel om beslissingen te faciliteren. En wanneer je met data en feiten kunt aantonen dat het risico voor de business minimaal is, dán is het moment gekomen om de testfase met een gerust hart te sluiten.
Ga met ons in overleg over de juiste aanpak voor uw onderneming tijdens een gratis online consult. Registreer uw consult met de CEO hier.
