De kwaliteit van testen gemeten met de bugs van klanten

Een acceptatietest door een klant is een geaccepteerde en professionele stap in je testproces. Maar het wordt een ander verhaal als je de acceptatietest gaat gebruiken om de echte kwaliteit van het interne testproces te verbergen: "Dit soort fouten zijn aan onze klanten om te vinden". Hoe voorkom je dit? Beoordeel je testproces aan de hand van de bugs, die je klanten terug melden. En kijk zowel naar de bugs uit de acceptatietest, als naar de bugs, die gevonden worden in productie.

Basis indeling

Er zijn drie belangrijke factoren, waaraan je kan zien hoe goed je testproces is, als je naar bugs kijkt:

1. Waar is de bug gevonden?
   Is de bug in de schermen, die de gebruiker (bijna) dagelijks gebruikt? Of is de bug in de schermen, die minder vaak gebruikt worden?
2. Hoe uitzonderlijk is de invoer?
   Is de ingevoerde combinatie van gegevens om de bug te reproduceren iets wat nauwelijks voorkomt? Of is het een combinatie, die (bijna) elke dag opnieuw gebruikt wordt? Let hier wel op: als je 500 producten hebt en het product waarmee je reproduceert is product 371, blijf eerlijk. Als de bug inderdaad op slechts 1 product reproduceerbaar is, is de invoer misschien zeer uitzonderlijk. Maar als je dezelfde bug ook kan reproduceren met 99 andere producten, is de reproduceerbaarheid toch echt een stuk hoger.
3. Hoe eenvoudig is de bug te reproduceren?
   Is de bug reproduceerbaar door gewoon willekeurige gegevens in te voeren? Of moet je bepaalde keuzes maken, om de bug te kunnen reproduceren, zoals een "Ja" kiezen in een combobox of een instelling in een ander instellingen scherm wijzigen?

 Let wel op dat ik hierbij bewust van een bug spreek. Een bug is iets wat niet goed werkt, waarvan iedereen zal zeggen: "Dit is gewoon fout". Dus situaties als "Dit veld hoort eigenlijk voor dat veld" of "De tab volgorde klopt niet" wordt binnen deze blog niet als bug gezien. Natuurlijk verdient dit ook aandacht en zegt het ook wat over je testkwaliteit. Maar als dit de belangrijkste problemen zijn, dan ben je echt al vrij hoog in de testkwaliteit.

Komen tot een tussenoordeel

Op basis van deze drie factoren kan een kwaliteitsschema worden opgesteld. 

Komen tot een eindoordeel

Wat hieronder staat, is mijn voorstel. Maar voel je vrij je eigen indeling te maken.

Kwaliteitsniveau 1Bijna bij elke RFC of story heeft een klantbug, die valt in minimaal 2 categorieën "Laag".

Kwaliteitsniveau 2
Bijna bij elke RFC of story heeft een klantbug, die valt in 1 categorie "Laag".

Kwaliteitsniveau 3
Bijna elke RFC of story heeft een klantbug, die valt in minimaal twee categorieën "Matig".

Kwaliteitsniveau 4
Bijna elke RFC of story heeft een klantbug, die valt in 1 categorie "Matig".


Kwaliteitsniveau 5
Bijna geen RFC of story heeft een klantbug in de categorie "Laag"

Kwaliteitsnviveau 6Bijna geen RFC of story heeft een klantbug in de categorie "Matig"

De kritische punten

De overlap
Ik besef dat de categorieën soms overlap hebben. Als een gegevenscombinatie dagelijks wordt ingevoerd, zal dit bijna altijd zijn in een scherm dat dagelijks gebruikt wordt. Dit kan misschien niet eerlijk lijken. Maar juist de schermen, die zo vaak gebruikt worden en waarin steeds dezelfde gegevenscombinaties ingevoerd worden, moeten ook minimaal op deze wijze getest worden. Als je in de meest gebruikte schermen niet de meest gebruikte gegevenscombinaties test, dan heb je echt je testproces niet op orde. En dat geldt ook voor andere overlap, die je kan bedenken. Juist dit zijn testen, die gewoon standaard uitgevoerd moeten worden.

Dit is toch niet nodig?
Er zijn al zoveel manieren om het kwaliteitsniveau te meten. Waarom zou je zoveel tijd steken in het meten op basis van bugs van klanten? Het zou ook niet nodig moeten zijn. Maar ik heb te vaak meegemaakt dat de kwaliteit van het product afgeschoven wordt op de klanten: "Dat moet de klant testen" of nog erger "Had de klant maar beter moeten testen, voor we naar productie gingen". Meestal gaat dit gepaard met ontevreden klanten, een slechte samenwerking met de klant en weinig vertrouwen van de klant in het bedrijf en product. Tenzij dit is wat je wil, kan het zeer verstandig zijn om bij bovenstaande beweringen eens goed na te gaan of je van je klant niet teveel testwerk verwacht.

In het kort

Het belangrjjkste is goed te kijken naar de bugs, die klanten melden. Hoe simpel was het om deze in een test te vinden. De volgende criteria kunnen hierbij een houvast zijn:

1. Waar is de bug gevonden?
2. Hoe uitzonderlijk is de invoer?
3. Hoe eenvoudig is de bug te reproduceren?

Hoe makkelijker en vaker de bugs voorkomen, hoe slechter de kwaliteit van je testproces. Gebeurt dit regelmatig, dan kan het zeer verstandig zijn een kwaliteitsschema op te stellen als hierboven, om de kwaliteit te controleren en te verbeteren. Maak gerust je eigen schema. Het belangrijkste doel is tenslotte: je interne testproces moet zo goed zijn, dat je klant tevreden is over de kwaliteit. Maar niet slechts de eindkwaliteit. Nee, ook de kwaliteit van het eerste product, dat de klant zal testen.