Gisteren zat ik met een collega een testtraining voor te bereiden. Ineens lag het daar op tafel. Zomaar tussen ons in. Zo voor het oprapen, lag daar een vraag te wachten om beantwoord te worden; Wat is de waarde van een fout?
De ROI van testen betwijfeld?
Deze vraag is interessant voor iedereen die graag de toegevoegde waarde van het testen wil aantonen. Vaak heeft men het over de Return Of Investment (ROI) en probeert men deze te berekenen aan de hand van onderstaande formule:
Met het Boehm principe als uitgangspunt, gaat deze formule ervan uit dat elke fout die vroegtijdig gevonden wordt geld oplevert. Men maakt een schatting van wat de herstelkosten van een fout als deze in productie wordt gevonden. Voor elke fout die je voortijdig vindt, maak je deze kosten niet en deze zijn dus een besparing. Een mooi verhaal, maar hoe schat je de herstelkosten in? De bovenstaande formule wordt regelmatig gebruikt, maar meestal pas in de projectevaluatie, of als de organisatie de ROI van testen betwijfeld.
Inschatten van je eigen effectiviteit
De vraag is ook interessant voor iedereen die graag kritisch kijkt naar zijn eigen effectiviteit. Als ik zelf aan het testen ben, houd ik mezelf graag de spiegel voor. Bij elke gevonden bug schat ik in of het een een ‘dure’ of ‘goedkope’ bug is. Vaak heb ik geen harde metrieken tot mijn beschikking en gebruik ik daarom de onderstaande formule. Deze formule levert geen waarde op in harde euro’s. De toepassing ervan zorgt er wel voor dat ik me regelmatig afvraag; Ben ik goed bezig?
Sommige bugs springen letterlijk van je computerscherm af. Deze bugs vind je niet, ze vinden jou. De Mean Time Between Bugs (MTBB) is erg klein en de inspanning om de fout te vinden is erg laag. In dit soort situaties is het niet moeilijk om de bevindingendatabase te vullen en de dag af te sluiten met een: ‘ik heb weer 40 fouten geregistreerd’. Echter, lang niet elke bug wordt opgelost. We kennen allemaal het fenomeen dat de ‘prioriteit-4’ bevindingen uiteindelijk nooit worden opgelost. Blijkbaar maakt niemand zich echt druk om deze fouten. Ondanks dat de fout snel gevonden was, is de waarde ervan dus laag. Alleen naar de kwantiteit kijken is blijkbaar onvoldoende.
De andere factor die de waarde van een fout bepaalt is de commotie. Hiermee bedoel ik de mate waarop belanghebbenden reageren als ze van de fout horen. Als een fout veel commotie veroorzaakt betekent dat, dat deze fout impact heeft. Hij wordt herkent als relevant, wordt niet aan de kant geschoven en krijgt prioriteit.
De toepassing
Als ik tijdens het testen een fout vermoed, maak ik graag snel de inschatting. Wat denk ik te gaan vinden, hoeveel tijd kost me dat en wie maakt zich druk over deze fout? Deze schatting helpt me beslissen of ik mijn gut-feeling ga najagen, of toch maar op zoek ga naar andere fouten. Het helpt me ook om een time-box te zetten en de inspanning te limiteren. Het helpt me om focus te houden op de juiste activiteiten en de waarde van mijn bevindingen te vergroten.
Dit laatste helpt me om de toegevoegde waarde van mijn werk overtuigend over de bühne te brengen. Niet kwantitatief, maar doordat de belanghebbenden ervaren dat de output van het proces toegevoegde waarde heeft. Doordat ze goedkeurend knikken en blij zijn dat deze fouten tijdig zijn gevonden.
——————
Derk-Jan de Grood werkt als testexpert bij Valori. Hij adviseert organisaties bij het inrichten en verbeteren van hun testactiviteiten. Als productmanager werkt hij aan innovaties in het Valori dienstaanbod. Daarnaast spreekt en publiceert hij met groot enthousiasme over ontwikkelingen in het testvak.
© Derk-Jan de Grood.
Wanneer je dergelijke dingen probeert om te zetten in geld, ben je voor een groot gedeelte afhankelijk van je eigen mening. Dat is natuurlijk hartstikke logisch, maar zo’n subjectiviteit kan gevaarlijk zijn.
Momenteel werk ik aan een project waar er ook getest moet worden op waarschuwingen en foutboodschappen voor een website. Soms worden deze boodschappen op het scherm net iets anders getoond dan hoe ze beschreven staan in de requirements. Op het eerste gezicht zijn dit futiele defecten, maar voor business kunnen die echter blokkerend zijn, omdat er ook een legaal luik aan te pas komt.
Daarom registreer ik alle defects – hoe onbelangrijk ze ook zijn – en vraag ik altijd de mening van iemand anders (kan ook via mail gebeuren) om zeker te zijn of het een defect is of niet. Helaas worden veel van die defects onder tijdsdruk dan weer geweigerd of geprioriteerd naar beneden, maar dat is weer een heel ander verhaal :-)
Beste Gert,
Ik ben het met je eens hoor. Als je een fout gevonden hebt, gewoon registreren. Zeker het sparren met een collega (tester,analist, gebruiker,ontwikkelaar) is altijd erg nuttig. Ik heb ergens het gevoel dat je het in jouw comment niet helemaal met me eens bent. Maar misschien lees ik teveel tussen de regels. Wat ik probeer te zeggen is dat ik voordat ik fouten vind, nadenk over wat ik zou kunnen vinden. je kent het wel, je komt iets tegen. je gut-feel zegt, hier klopt iets niet. Ga je de fout najagen, en hoelang ga je door…. Zekerheden zijn er niet in het testers-leven. Je weet nooit welke verschrikkelijke fout er onverwachts om de hoek verschijnt. Toch helpt het mij om even een forcast te maken, en dan te besluiten of ik van mijn pad afdwaal of doorloop.
Derk-Jan