Stel je voor: je bent test manager bij een softwarebedrijf en je besluit om je test strategie checken op de agenda te zetten. Alleen, waar begin je? De strategie die twee jaar geleden werd opgesteld, draait nog steeds ongewijzigd. Maar het team is verdubbeld, jullie releasen nu wekelijks in plaats van maandelijks, en er zijn drie microservices bijgekomen. Past die oude strategie daar eigenlijk nog bij?
Dit komt verrassend vaak voor. Teams steken weken in het opzetten van een teststrategie, maar evalueren hem daarna nooit meer. En dat is een probleem, want context verandert voortdurend: je product evolueert, je team groeit, en je technologie moderniseert. Je teststrategie zou moeten meebewegen, maar in de praktijk staat hij stil.
In dit artikel krijg je 7 vragen waarmee je je test strategie checken kunt op een gestructureerde manier. Geen vage theorie, maar concrete checkpoints met een self-assessment per vraag. Plus een scorecard waarmee je direct ziet waar je staat en waar je moet bijsturen. Binnen 10 minuten weet je precies waar de schoen wringt.
Waarom een verouderde teststrategie je stilletjes geld kost
Je test strategie checken voelt misschien als iets dat "later wel kan". Maar een verouderde strategie kost je meer dan je denkt, niet in een grote klap, maar druppelsgewijs. Elke week een paar uur verspild aan tests die niets meer opleveren. Elke sprint een bug die door je net glipt omdat je de verkeerde dingen test.
Neem bijvoorbeeld een e-commerce team dat twee jaar geleden hun teststrategie opzette rondom hun desktop webshop. Sindsdien is 60% van hun verkeer naar mobiel verschoven, maar hun testsuite dekte nog steeds voornamelijk desktop-scenario's. Resultaat: drie kritieke mobiele bugs in twee maanden die pas na klachten van klanten werden gevonden. Dat had voorkomen kunnen worden met een simpele halfjaarlijkse check.
Een goede vuistregel is daarom om test strategie checken minimaal elke zes maanden te doen. Hoe een teststrategie er in de basis uitziet, legt het ISTQB glossary uit bij de definitie van test strategy. Niet als bureaucratische exercitie, maar als strategisch moment om te checken of je testinspanning nog aansluit bij je huidige werkelijkheid. Lees ook ons artikel over een teststrategie ontwikkelen als je je strategie vanaf de basis wilt opbouwen.
Maar waar begin je precies als je je test strategie wilt checken? Bij deze 7 vragen.
De 7 vragen in een overzicht
| # | Vraag | Focus |
|---|---|---|
| 1 | Dekken je tests de business risks? | Risico-afstemming |
| 2 | Wat is je automation ratio? | Snelheid |
| 3 | Hoe snel krijg je feedback? | Feedbacktijd |
| 4 | Test je de juiste dingen? | Strategische focus |
| 5 | Wie is eigenaar van kwaliteit? | Eigenaarschap |
| 6 | Hoe vaak update je je strategie? | Actualiteit |
| 7 | Wat is de ROI van je testing? | Bedrijfswaarde |
Laten we elke vraag doorlopen, met concrete handvatten om jezelf eerlijk te beoordelen.
Dekken je tests nog steeds wat er echt toe doet?
De eerste vraag bij test strategie checken gaat over de aansluiting tussen je tests en je zakelijke risico's. Business priorities verschuiven voortdurend, en je testinspanning moet daarin meebewegen. Wat twee jaar geleden je belangrijkste feature was, is dat nu misschien niet meer.
Stel je een fintech startup voor die begon met een eenvoudig betaalproduct. Hun tests dekten dat grondig. Maar inmiddels is hun grootste inkomstenbron een abonnementenmodule die ze een jaar geleden lanceerden, en juist die module heeft nauwelijks testdekking (de mate waarin je code en functionaliteit door tests wordt afgedekt). Elke bug daar raakt direct de omzet.
Check jezelf: kun je de top 3 zakelijke risico's benoemen? Zijn daar tests voor? Is je testinspanning evenredig aan het risiconiveau? En worden die risico's regelmatig heroverwogen?
Als je niet eens weet wat de grootste zakelijke risico's zijn, of als je testdekking nog gericht is op oude features die niet meer kritiek zijn, dan is dat een duidelijk signaal. Risicomanagement in software development is ook uitgebreid beschreven op Wikipedia als basis voor bewuste prioritering. Breng je zakelijke risico's in kaart en leg ze naast je huidige testdekking. Gebruik daarbij een risicomatrix: de combinatie van kans en impact bepaalt je testprioriteit. Voor meer over deze aanpak, zie ons artikel over risk-based testing.
Heb je test strategie checken op risico-afstemming afgerond? Dan is de volgende logische vraag: hoe snel kun je daarop testen?
Klopt je automation ratio nog bij hoe je nu werkt?
Je automation ratio (het percentage geautomatiseerde tests ten opzichte van je totale testsuite) bepaalt in grote mate hoe snel je feedback krijgt. En die snelheid moet passen bij hoe vaak je releast.
Een concreet voorbeeld: een team dat twee jaar geleden maandelijks releasete, had 30% van hun tests geautomatiseerd. Dat werkte prima, want er was voldoende tijd voor handmatige tests tussen releases door. Maar nu releasen ze dagelijks, en diezelfde 30% automatisering is een flessenhals geworden. Developers wachten uren op handmatige testresultaten terwijl ze allang aan de volgende feature werken.
Check jezelf: weet je wat jullie automation ratio is? Past dat bij jullie releasefrequentie? Kunnen jullie binnen 30 minuten feedback geven op een commit? En zijn handmatige tests een bewuste keuze, of is het simpelweg "geen tijd gehad om te automatiseren"?
Als vuistregel geldt: bij dagelijkse releases heb je 70 tot 90 procent automatisering nodig, bij wekelijkse releases is 50 tot 70 procent werkbaar, en bij maandelijkse releases kom je met 30 tot 50 procent een heel eind. Maar let op: een ratio van 90% terwijl je maandelijks releast, is waarschijnlijk te veel van het goede. Context bepaalt dus het juiste getal. Lees ons test automation artikel voor meer over de juiste verdeling.
Maar automatisering alleen is niet voldoende. Want hoeveel tests je ook automatiseert, als de doorlooptijd (de totale tijd die je testsuite nodig heeft om te draaien) te lang is, heb je alsnog een probleem.
Hoe snel weet je eigenlijk of je code werkt?
Feedbacksnelheid bepaalt hoe effectief je team werkt. Snelle feedback betekent snelle fixes, want de developer zit nog midden in de context van de code. Trage feedback daarentegen leidt tot contextswitching (het voortdurend moeten schakelen tussen taken), en dat maakt bugfixes twee tot tien keer duurder.
Neem een team bij een SaaS-bedrijf als voorbeeld. Hun regressiesuite duurde acht uur. Niemand draaide die suite meer overdag, want wie wil acht uur wachten? Dus draaiden ze hem 's nachts. Maar als er om 3 uur 's nachts een test faalde, keek niemand tot de volgende ochtend. Tegen die tijd was de developer alweer met iets anders bezig en kostte een bugfix die in 10 minuten had kunnen, nu 2 uur.
Check jezelf: draaien je smoke tests binnen 15 minuten na een commit? Is je kernregressie binnen 2 uur klaar? Blijft je volledige suite onder de 8 uur? En krijgen developers feedback terwijl de context nog vers is?
Als developers langer dan een uur wachten op testresultaten, of als je tests niet in je CI/CD-pipeline draaien (het automatische proces dat code bouwt, test en klaarmaakt voor release), verlies je kostbare tijd. Meet je huidige feedbacktijden, splits lange suites op in lagen (smoke, regressie, volledig), en pak instabiele tests als eerste aan. Die zogenaamde flaky tests (tests die soms falen zonder duidelijke reden) zijn namelijk de grootste tijdverspillers. Zie onze CI/CD testing best practices voor concrete tips.
Tot zover de technische kant van test strategie checken. Maar er is een fundamentelere vraag die veel teams over het hoofd zien: test je eigenlijk wel de juiste dingen?
Test je de juiste dingen, of test je gewoon alles?
Honderd procent testdekking klinkt als een mooi streven. Maar in de praktijk betekent het vaak dat je admin panel (gebruikt door vijf mensen, een keer per week) evenveel testinspanning krijgt als je checkout-flow (tienduizend transacties per dag). En eerlijk? Dat is verspilling.
De Pareto-regel geldt ook voor testen: ruwweg 20% van je tests vindt 80% van je bugs. De kunst is dus om te weten welke 20% dat is, en daar je energie op te richten. Bij een webshop bijvoorbeeld bleek na analyse dat drie van hun vijftig testscenario's verantwoordelijk waren voor het vangen van meer dan de helft van alle bugs. Dat waren de scenario's rondom betaling, voorraadverwerking en accountregistratie.
Check jezelf: testen jullie op basis van risico, of krijgt alles dezelfde aandacht? Weten jullie welke tests de meeste waarde opleveren? Verwijderen jullie tests die niets meer opleveren? En is testdekking een middel of een doel op zich geworden?
Als je testsuite alleen maar groeit en nooit krimpt, is dat een waarschuwingssignaal. Plan daarom elk kwartaal een opschoonsessie. Tests die in zes maanden niet zijn gefaald, die verouderde functionaliteit dekken, of die andere tests dupliceren, zijn kandidaten om te verwijderen. Het klinkt misschien eng om tests weg te gooien, maar een kleinere suite die de juiste dingen dekt is waardevoller dan een enorme suite die alles half dekt.
Maar zelfs de beste testsuite helpt niet als niemand zich verantwoordelijk voelt voor kwaliteit. En dat brengt ons bij een vraag die vaker pijn doet dan je zou verwachten.
Van wie is kwaliteit eigenlijk?
Kwaliteit is een teamsport, geen taak voor alleen de tester. Toch hoor je het nog regelmatig: "Testing? Dat is toch de taak van de tester?" En zodra die mentaliteit er is, wordt de tester een flessenhals waar al het testwerk doorheen moet.
Bij een team van een verzekeringsmaatschappij speelde dit probleem duidelijk. De twee testers waren continu overbelast, terwijl de zes developers code opleverden zonder een enkele test te schrijven. Doorlooptijden liepen op, bugs stapelden zich op, en de testers begonnen noodgedwongen shortcuts te nemen. Pas toen het team kwaliteit als gedeelde verantwoordelijkheid oppakte (developers schrijven unit tests, testers richten zich op integratietests en coaching) verbeterde de situatie merkbaar. Binnen twee sprints halveerde het aantal bugs dat de testfase bereikte.
Check jezelf: schrijven developers tests voor hun eigen code? Is de product owner betrokken bij de teststrategie? Bespreekt het team kwaliteit in retrospectives? En staat kwaliteit expliciet in de Definition of Done (de afspraken over wanneer werk "af" is)?
Als "testen is niet mijn taak" een veelgehoorde uitspraak is in je team, of als je testers de enige flessenhals zijn, is het tijd om eigenaarschap breder te leggen. Neem kwaliteit op in je Definition of Done met concrete criteria, en bespreek in elke retrospective welke kwaliteitsproblemen er speelden en hoe het team die samen kan voorkomen.
Eigenaarschap gaat over cultuur. Maar cultuur moet ook onderhouden worden, net als je strategie zelf. En daarover gaat de volgende vraag.
Wanneer heb je je strategie voor het laatst bijgewerkt?
Een teststrategie is geen document dat je eenmaal schrijft en daarna in een la legt. Het is een levend plan dat meebeweegt met je context. En toch gebeurt het regelmatig dat een strategie twee jaar of langer ongewijzigd blijft.
Denk aan een team dat hun teststrategie schreef toen ze met vijf developers werkten aan een monolithische applicatie. Inmiddels zijn ze met vijftien developers, werken ze met microservices, en hebben ze drie keer zoveel functionaliteit. Maar de teststrategie beschrijft nog steeds de oude situatie, inclusief testtypes en prioriteiten die niet meer kloppen.
Check jezelf: is je teststrategie in de afgelopen zes maanden herzien? Passen jullie de strategie aan bij grote productwijzigingen? Geeft het team input bij strategie-updates? En is de strategie gedocumenteerd, of bestaat hij alleen in het hoofd van de test manager?
De minimale frequentie voor een strategiereview is elke zes maanden, maar elk kwartaal is beter. Dan kun je de strategie direct afstemmen op de productroadmap. Documenteer je strategie op maximaal twee pagina's zodat het leesbaar en toegankelijk blijft, en betrek je team bij updates via een korte workshop. Want een strategie die het hele team kent en begrijpt, werkt beter dan een perfect document dat niemand leest.
De laatste vraag bij test strategie checken is misschien wel de lastigste, maar ook de belangrijkste als je draagvlak nodig hebt bij management: wat levert al dat testwerk eigenlijk op?
Wat levert je testing eigenlijk op?
Testing kost tijd en geld, dat is duidelijk. Maar kun je ook aantonen wat het oplevert? Voor veel teams is het eerlijke antwoord: nee. En dat is een gemiste kans.
Want juist de meetbaarheid van testing (je return on investment, oftewel ROI: de verhouding tussen wat testing kost en wat het oplevert) geeft je de argumenten om meer of anders te investeren. Lees ook hoe je de kosten van software testen kunt optimaliseren als onderdeel van je strategiereview. Stel je een test manager voor die aan het management wil uitleggen waarom het team een extra automation engineer nodig heeft. Zonder cijfers is dat een lastig gesprek. Maar met concrete data ("vorig kwartaal hebben onze tests 23 bugs voor productie gevangen, wat ons naar schatting 115.000 euro aan productieverstoringen heeft bespaard") wordt het een heel ander verhaal.
Check jezelf: meten jullie testmetrics zoals het aantal bugs dat in de testfase wordt gevonden versus productie? Kunnen jullie de bug detection rate (het percentage bugs dat voor productie wordt gevonden) berekenen? Weten jullie wat testing kost versus wat bugs in productie kosten? En ziet het management de waarde van de testinvestering?
Begin simpel met meten: tel hoeveel bugs je tests vangen versus hoeveel er in productie opduiken. Reken de kosten door met een gangbaar gemiddelde van 5.000 tot 15.000 euro per productiebug (inclusief onderzoek, hotfix en reputatieschade). De relatie tussen kosten en late defectdetectie is goed gedocumenteerd in de kromme van Boehm. Communiceer deze cijfers vervolgens in je kwartaalreviews naar management. Want wat je kunt meten, kun je verbeteren. En wat je kunt aantonen, krijgt budget.
Scorecard: test strategie checken met een score
Tel je positieve antwoorden bij alle zeven vragen (vier checkpunten per vraag, 28 in totaal). Elk "ja" op een checkpunt is een punt.
| Score | Beoordeling | Wat het betekent |
|---|---|---|
| 24-28 | Uitstekend | Je teststrategie is gezond en strategisch afgestemd. Behoud je kwartaalreviewcyclus en deel je aanpak met andere teams. |
| 16-23 | Verbeterpunten | Sommige gebieden zijn sterk, andere zwak. Focus op de drie laagst scorende vragen en start een vaste reviewcyclus. |
| 8-15 | Kritiek | Er zijn fundamentele hiaten in je aanpak. Plan een volledige strategiereview en begin bij vraag 1: de afstemming op zakelijke risico's. |
| 0-7 | Urgent | Er is nauwelijks sprake van een bewuste strategie. Stop met ad-hoc testen en bouw je aanpak opnieuw op vanaf de basis. |
Kijk daarnaast welke specifieke vragen het laagst scoren. Daar zit de meeste winst: scoor je laag op vraag 1? Dan is risico-afstemming je grootste zorg. Laag op vraag 2 of 3? Dan zit het probleem in snelheid en automatisering. Laag op vraag 5? Dan is het een cultuurvraagstuk.
Wat je morgen anders kunt doen
Test strategie checken hoeft niet alles-of-niets te zijn. Je hoeft niet alle zeven vragen tegelijk aan te pakken. Pak de vraag waar je het laagst scoort en begin daar. Plan deze week een half uur met je team om de vragen samen door te lopen, eerlijk en zonder schoonheid. Bereken je score, kies de drie grootste hiaten, en blokkeer over twee weken een uurtje om de eerste verbeteringen te bespreken.
Want een teststrategie die twee jaar geleden werkte, werkt nu waarschijnlijk niet meer. Maar het goede nieuws is dat je door test strategie checken met deze zeven vragen binnen tien minuten weet waar je staat. En dat is precies de eerste stap naar een strategie die weer past bij hoe je team vandaag werkt.
Wil je eens sparren over wat je met je scores kunt doen, of benieuwd hoe je je test strategie checken en vernieuwen kunt? We denken graag vrijblijvend met je mee. Plan een gesprek
