Je kent de discussie vast. Tijdens een refinement of bij een code review komt de vraag voorbij: hebben we wel genoeg test coverage? En dan begint het. De een roept dat 80 procent de standaard is. Een ander vindt dat je naar 100 procent moet streven. En ergens in de hoek zit iemand die mompelt dat coverage toch maar een getal is.
Wie heeft er gelijk? Eerlijk gezegd: niemand. En iedereen een beetje.
Het juiste percentage hangt namelijk af van je situatie. Maar dat betekent niet dat je er maar wat op moet gokken. In dit artikel deel ik een praktisch framework waarmee je bepaalt welk percentage voor jouw project logisch is. Geen heilige graal, wel een onderbouwde aanpak die je morgen kunt toepassen.
Waarom 100 procent coverage zelden een goed doel is
Laten we beginnen met het ene uiterste. Je zou denken: hoe meer coverage, hoe beter toch? Maar in de praktijk werkt dat anders. Streven naar 100 procent leidt vaak tot precies het tegenovergestelde van wat je wilt bereiken.
Het getal wordt belangrijker dan de waarde
Zodra 100 procent het doel wordt, gaan ontwikkelaars tests schrijven om het getal omhoog te krijgen. Niet om daadwerkelijk fouten te vinden. Je krijgt dan tests voor getters en setters die niets anders doen dan een waarde teruggeven. De coverage stijgt, maar de kwaliteit van je testsuite? Die daalt.
Een concreet voorbeeld: stel je test een methode getName() die alleen this.name teruggeeft. Prima, je hebt 100 procent coverage op die methode. Maar wat heb je eigenlijk getest? Niets zinvols.
De wet van de afnemende meerwaarde
Van 0 naar 80 procent coverage brengen kost relatief weinig moeite en levert veel op. Je dekt de belangrijkste logica af, de happy paths, de meest voorkomende scenario’s. Maar van 80 naar 95 procent? Dat kost al flink meer tijd voor minder rendement. En die laatste 5 procent naar 100? Daar ben je soms net zo lang mee bezig als met de eerste 80 procent bij elkaar.
Onderzoek van Google bevestigt dit: het verhogen van coverage van 80 naar 100 procent kost gemiddeld vier keer zoveel tijd als de stap van 0 naar 80 procent. Dat is een flinke investering voor een beperkte meerwaarde.
Vals gevoel van zekerheid
En dan is er nog iets dat we niet mogen vergeten: 100 procent coverage betekent niet dat je software foutloos is. Coverage meet alleen welke regels code worden uitgevoerd tijdens het testen. Niet of je de juiste dingen test.
Neem deze simpele functie:
def deel(a, b):
return a / bJe kunt hier makkelijk 100 procent coverage halen met één test: deel(10, 2). Maar wat gebeurt er als iemand deel(10, 0) aanroept? Precies, een crash. Je coverage was perfect, je test niet.
Onderhoudslast
Meer tests betekent ook meer onderhoud. Bij een grote refactoring kan 30 tot 40 procent van je testsuite updates nodig hebben. Als een groot deel van die tests triviale code afdekt, ben je vooral bezig met het repareren van tests die weinig waarde toevoegen. Zonde van je tijd.
Waarom 0 procent coverage ook geen optie is
Het andere uiterste dan. Soms hoor je: “Tests zijn overhead, we hebben geen tijd voor tests.” Begrijpelijk sentiment als de druk hoog is. Maar op de lange termijn betaal je daar een hoge prijs voor.
Zonder tests heb je geen vangnet. Refactoren wordt eng, want je weet niet of je iets kapotmaakt. Regressiebugs sluipen erin. Technische schuld stapelt zich op. En deployments? Die duren vier keer zo lang omdat je alles handmatig moet controleren.
We zagen dit bij een fintech startup die zonder geautomatiseerde tests werkte. Elke deployment ging gepaard met uitgebreide handmatige testsessies. Het team was meer tijd kwijt aan controleren dan aan bouwen. Na het invoeren van een testsuite met 60 procent coverage daalde de deploymenttijd met 60 procent. Het team kon eindelijk weer vooruit.
De minimale basis is dus:
- Kritieke paden: altijd testen
- Kernlogica van je applicatie: altijd testen
- Randgevallen: waar mogelijk
- Getters en setters zonder logica: overslaan
Vier factoren die je coverage-doel bepalen
Goed, we weten nu dat 100 procent meestal te veel is en 0 procent te weinig. Maar hoe bepaal je dan wat voor jouw situatie het juiste percentage is? Dat hangt af van vier factoren.
Factor 1: hoe kritiek is je applicatie?
De eerste vraag die je moet stellen: wat zijn de gevolgen als er een bug in productie komt?
Bij een applicatie die betalingen verwerkt of medische gegevens beheert, zijn de gevolgen van een fout potentieel desastreus. Dan is een coverage van 85 tot 95 procent logisch. De investering in tests weegt op tegen het risico.
Bij een interne tool die alleen door je eigen team wordt gebruikt? Dan is 40 tot 60 procent vaak prima. Een bug is vervelend, maar niet rampzalig.
En bij een e-commerce platform of een SaaS-applicatie zit je er tussenin. Bugs leiden tot gefrustreerde klanten en mogelijk omzetverlies, maar zijn zelden catastrofaal. Denk aan 70 tot 85 procent.
Factor 2: hoe vaak deploy je?
De tweede factor is je deployfrequentie.
Als je meerdere keren per dag naar productie deployt, heb je een stevig vangnet nodig. Er is simpelweg geen tijd voor uitgebreide handmatige tests tussen elke deployment. Dan wil je richting 80 procent of hoger.
Deploy je maandelijks? Dan heb je meer ruimte voor handmatige regressietests en kun je met een lagere coverage prima uit de voeten. Rond de 60 procent kan dan voldoende zijn.
Factor 3: hoe ervaren is je team?
De derde factor is de ervaring binnen je team.
Bij een team met veel junior ontwikkelaars fungeren tests niet alleen als vangnet, maar ook als documentatie en leermiddel. Ze laten zien hoe de code bedoeld is te werken. Een hogere coverage, richting 80 procent, helpt het team om sneller te groeien en minder fouten te maken.
Bij een ervaren team dat goed aanvoelt waar de risico’s zitten, kun je met een lagere coverage toe. Seniors herkennen de plekken waar tests echt nodig zijn en waar niet.
Factor 4: hoe complex is je code?
Tot slot: de complexiteit van je codebase.
Heb je veel complexe domeinlogica? Denk aan financiële berekeningen, algoritmes of state machines. Dan is een hoge coverage cruciaal, omdat het lastig is om alle scenario’s in je hoofd te houden. Richt je op 80 tot 90 procent.
Is je applicatie vooral rechttoe rechtaan CRUD-functionaliteit? Simpele database-operaties zijn makkelijker te overzien. Dan is 60 tot 70 procent vaak voldoende.
Een praktisch framework om je doel te bepalen
Nu wordt het concreet. Ik deel een framework dat we in de praktijk gebruiken om tot een onderbouwd coverage-doel te komen. Geen nattevingerwerk, maar een gestructureerde aanpak.
Stap 1: scoor je project op de vier factoren
Geef je project een score van 1 tot 5 op elke factor:
Kriticiteit van je applicatie
- 1 = interne tool, prototype
- 3 = e-commerce, standaard SaaS
- 5 = financiële diensten, medische software, veiligheidskritieke systemen
Deployfrequentie
- 1 = maandelijks of minder
- 3 = wekelijks
- 5 = meerdere keren per dag
Teamervaring
- 1 = voornamelijk junior ontwikkelaars
- 3 = gemengd team
- 5 = voornamelijk senior experts
Codecomplexiteit
- 1 = simpele CRUD-operaties
- 3 = gemiddelde businesslogica
- 5 = complexe algoritmes en domeinlogica
Stap 2: bereken je gewogen score
Niet elke factor weegt even zwaar. Kriticiteit heeft de meeste impact, gevolgd door complexiteit en deployfrequentie. Teamervaring weegt het minst, omdat het vooral invloed heeft op hoe je tests schrijft, niet zozeer op hoeveel je nodig hebt.
De formule:
Totaalscore = (kriticiteit × 0,30) + (deployfrequentie × 0,25) +
(teamervaring × 0,20) + (complexiteit × 0,25)Stap 3: vertaal je score naar een coverage-doel
| Score | Coverage-doel | Toelichting |
|---|---|---|
| 4,0 – 5,0 | 85 – 95% | Missiekritiek, veel verandering, uitgebreid testen |
| 3,0 – 3,9 | 70 – 85% | Belangrijk, gematigd risico, gebalanceerde aanpak |
| 2,0 – 2,9 | 60 – 70% | Lager risico, focus op kritieke paden |
| 1,0 – 1,9 | 40 – 60% | Prototype of lage kriticiteit |
Een voorbeeld uit de praktijk
Laten we dit toepassen op een concrete situatie. Stel, je werkt aan een webshop voor een moderetailer met 50.000 bestellingen per maand.
De scores:
- Kriticiteit: 4 (omzetimpact, klantgegevens, bestelverwerking)
- Deployfrequentie: 4 (twee keer per dag, CI/CD-pipeline)
- Teamervaring: 3 (gemengd team met seniors en mediors)
- Complexiteit: 3 (prijslogica, voorraad, checkout-flow)
De berekening:
(4 × 0,30) + (4 × 0,25) + (3 × 0,20) + (3 × 0,25) =
1,20 + 1,00 + 0,60 + 0,75 = 3,55Het doel: 70 tot 85 procent coverage
Dat betekent concreet: focus je coverage op de checkout-flow en betaalintegratie (daar wil je richting 90 procent), besteed serieuze aandacht aan voorraadbeheer (75 tot 80 procent), en wees wat relaxter over de productcatalogus (60 tot 70 procent is prima).
Hoe andere organisaties het aanpakken
Het helpt om te weten wat gangbaar is in verschillende sectoren. Niet om blind te kopiëren, maar om je eigen keuze in perspectief te plaatsen.
Luchtvaart en medische software: 90 tot 100 procent. Hier gelden strenge regelgevingseisen zoals DO-178C en IEC 62304. Fouten kunnen letterlijk levens kosten.
Financiële dienstverlening: 80 tot 90 procent. Hoog risico, strenge audits voor compliance met regelgeving als PSD2 en SOX.
Enterprise software: 70 tot 80 procent. Balans tussen kwaliteit en snelheid.
Startups en MVP’s: 40 tot 60 procent. Snelheid is belangrijker dan perfectie, en de kans is groot dat de code sowieso nog flink gaat veranderen.
Uit de Stack Overflow Developer Survey van 2024 blijkt dat de mediaan coverage op 72 procent ligt. De best presterende teams zitten boven de 85 procent, de laagst scorende onder de 50 procent.
Maar onthoud: benchmarks zijn geen targets. Jouw context is belangrijker dan het gemiddelde van je branche.
Coverage is een hulpmiddel, geen doel op zich
Dit is misschien wel de belangrijkste les: test coverage is een indicator, geen eindbestemming.
Focus op het schrijven van waardevolle tests. De coverage volgt dan vanzelf. Jaag niet op een percentage door slechte tests te schrijven.
Metrics die er wel toe doen
In plaats van alleen naar coverage te kijken, zijn dit de vragen die je zou moeten stellen:
Hoeveel bugs vangen we in test versus productie? Als het merendeel van je bugs pas in productie opduikt, zegt dat iets over de effectiviteit van je tests, niet over de hoeveelheid.
Hoe zeker voelt het team zich bij een deployment? Vraag het gewoon eens. “Op een schaal van 1 tot 10, hoe comfortabel voel je je om nu naar productie te deployen?” Dat gevoel zegt vaak meer dan een getal.
Hoe snel ontdekken we problemen? De tijd tussen het introduceren van een bug en het ontdekken ervan is een betere graadmeter dan coverage alleen.
Metrics die misleidend kunnen zijn
Coverage als losstaand getal is gevaarlijk. Een team kan 95 procent coverage hebben en toch de helft van de productieproblemen missen, simpelweg omdat de tests oppervlakkig zijn. Ze checken of de code draait, niet of de businesslogica klopt.
Het aantal tests zegt ook weinig. Kwantiteit is geen kwaliteit. Tien goed doordachte tests kunnen meer waarde hebben dan honderd oppervlakkige.
Een cultuuromslag
Vier het als je team bugs vindt in de testfase. Dat is het hele punt van testen. “We hebben deze sprint twaalf bugs in staging gevonden” is een grotere prestatie dan “We hebben onze coverage met 5 procent verhoogd.”
Samenvatting
Er is geen magisch percentage. Je context bepaalt je doel. Gebruik het framework: scoor de vier factoren, bereken je gewogen score, en vertaal die naar een realistisch coverage-doel.
De kern:
- 100 procent is meestal het verkeerde doel vanwege afnemende meerwaarde en het risico dat het getal belangrijker wordt dan de inhoud
- 0 procent is ook geen optie, want zonder vangnet wordt elke wijziging een risico
- Vier factoren bepalen je doel: kriticiteit, deployfrequentie, teamervaring en codecomplexiteit
- Het framework geeft je een onderbouwde basis in plaats van nattevingerwerk
- Coverage is een hulpmiddel om kwaliteit te meten, geen doel om na te jagen
Aan de slag
Pak de vier factoren erbij en scoor je huidige project. Dat kost je hooguit vijf minuten. Bereken je gewogen score en kijk waar je uitkomt. Bespreek het resultaat met je team en maak afspraken over waar je je test-inspanningen op richt.
Het gaat niet om het perfecte percentage. Het gaat erom dat je bewust kiest waar je je tijd in steekt, gebaseerd op wat voor jouw situatie het meeste oplevert.
Succes ermee. En als je er niet uitkomt of even wilt sparren over je teststrategie, neem dan gerust contact met ons op.
