80% coverage. Slaap je daar gerust op?

Coverage is een van de meest misleidende metrics in softwarekwaliteit. Van coverage als doel naar coverage als kompas.

80% coverage. Het staat in het dashboard, het is groen, en het voelt goed. De vraag is alleen: waar geeft dat cijfer je precies zekerheid over?

Coverage is een van de meest gebruikte en meest misbegrepen metrics in softwarekwaliteit. Niet omdat het een slechte metric is, maar omdat mensen er iets uit lezen wat er niet staat.

Wat coverage wél vertelt

Coverage vertelt je welk deel van je code (of je requirements, afhankelijk van hoe je het meet) door minstens één test wordt aangeraakt. Dat is nuttige informatie. Als 40% van je code nooit door een test heen komt, weet je waar je blinde vlekken zitten.

Wat coverage níet vertelt

En daar zit de valkuil. Een hoge coverage betekent niet automatisch dat je goede tests hebt. Een test die enkel een functie aanroept zonder iets te controleren, verhoogt je coverage. Ook een test die alleen de happy path doorloopt en belangrijke edge cases overslaat, telt gewoon mee.

Je kunt 90% coverage hebben op een codebase die faalt zodra een gebruiker iets onverwachts doet. En je kunt 60% coverage hebben op een codebase die solide is, omdat die 60% precies de kritieke paden dekt en grondig getest is.

Het gevaar van het cijfer als doel

Zodra coverage een target wordt, "we moeten naar 80%", begint het zijn eigen realiteit te vormen. Teams schrijven tests om het cijfer te halen, niet om risico af te dekken. Ze testen getters en setters, want dat gaat snel. Ze laten de ingewikkelde, risicovolle logica links liggen, want daar kost een goede test tijd.

Het resultaat: een hoger cijfer, maar niet meer zekerheid. Dat is niet onschuldig, dat is schadelijk. Want dat cijfer wordt gebruikt om beslissingen op te nemen.

De omslag: van doel naar kompas

Coverage is op zijn best als diagnostisch instrument, niet als doelstelling. Gebruik het om vragen te stellen, niet om ze te beantwoorden.

• Welke delen van de code raken we nooit aan? En is dat erg?
• Is onze kritieke business-logica beter gedekt dan onze randfunctionaliteit?
• Daalt onze coverage plots? Wat is er dan gebeurd?
• Waar hebben we veel code en weinig tests? Daar zit ons risico.

De vraag die er echt toe doet

Niet: "halen we 80%?" Maar: "durven we dinsdagmiddag naar productie te gaan?"

Als het antwoord ja is, en je coverage is 65%, dan is er niets aan de hand. Als het antwoord nee is, en je coverage is 85%, dan meet je het verkeerde.

Kwaliteit is geen percentage. Het is vertrouwen, en dat verkrijg je met tests die iets betekenen.