Software testen: het kost wat, maar dan heb je ook wat! Ja toch? Het is heel normaal als 30 tot 50 procent van je totale projectkosten er aan op gaan. Dat zijn breed geaccepteerde project management kentallen van goeroes als Fred Brooks, Capers Jones en Tom DeMarco. Maar welke ‘business benefits’ krijg je daarvoor nou precies terug?
Met andere woorden: waaróm wil je jouw it-systeem goed testen? Een open deur-vraag zou je denken, maar ik merk dat lang niet iedere business stakeholder zijn of haar antwoord paraat heeft. Daarmee doen ze zichzelf te kort. Mag ik een suggestie doen? Hier gaat ‘ie: de drie redenen waarom je software wil testen zijn: kwaliteitsborging, draagvlak en stuurinformatie.
In de praktijk merk ik dat de eerste reden meestal op waarde wordt geschat, de tweede veel minder en de derde vrijwel nooit. Dit komt overeen met de stelling van Gartner dat managers de business waarde van testen onderschatten. Behalve fouten vinden en kwaliteit bewaken (nummer één) is softwaretesten ook de manier om draagvlak en acceptatie bij je gebruikers op te halen (nummer twee). En testen levert de feitelijke stuurinformatie die je nodig hebt om te voorkomen dat je project mislukt (nummer drie).
Reden 1: kwaliteitsborging
Deze eerste reden snapt iedereen. Het liefst doe je de dingen in één keer goed, maar omdat systeemontwikkeling een creatief proces is en omdat wij mensen nu eenmaal fouten maken die vervelende consequenties kunnen hebben, moet er een vangnet zijn. Met dat vangnet halen we er zoveel mogelijk fouten uit en op basis van de ervaringen kunnen we uitspraken doen over de kwaliteit.
Reden 2: draagvlak
Resultaat is kwaliteit * acceptatie. Voor die acceptatie zijn goed informeren en communiceren heel belangrijk. Maar wat is met stip de beste manier om draagvlak en buy-in bij gebruikers te creëren? Testen natuurlijk! Geef ze een rol en een stem voor alle stappen van de acceptatietest (voor, tijdens en na). Hierdoor zal alle kritiek en potentieel negatieve emoties positief worden gekanaliseerd. Vraag – het liefst in een goed geregisseerde risicoworkshop – waar ze wakker van liggen en doe je acceptatieregie met een rode draad van risico’s naar testrapportage.
Reden 3: stuurinformatie
Projectvoortgangsrapportages zijn notoir onbetrouwbaar: ze worden nooit objectief en belangeloos ingevuld. De spreekwoordelijke laatste 20 procent die 80 procent van de tijd blijkt te pakken hoeft geen nadere toelichting. Bovendien is voortgang zonder kwaliteit geen voortgang. Goed testen is hiervoor de beste oplossing: het levert de feitelijke en betrouwbare stuurinformatie voor je projectbesturing en it-governance.
Conclusie
Kortom: testen levert je meer kwaliteit, meer draagvlak en betere stuurinformatie.
Vergeet die laatste twee niet!
In mijn blog ‘De drie redenen waarom we software testen’ ga ik nog wat uitgebreider in op de concrete ‘goodies’ in dit verband. Ik kijk uit naar een goede discussie!
Hallo Egbert,
Dit vind ik echt een voorbeeld van een goed artikel over software testen.
Keep up the good work!
“30 tot 50 procent van je totale projectkosten”
“Dat zijn breed geaccepteerde project management kentallen”
vast wel, maar het zijn geen breed geaccepteerde stuurgetallen.
Laat ik het zo zeggen : tarief scherp.
Dankjewel heren!
@Felix: als je de verborgen testuren meerekent zijn het geen gekke cijfers hoor!
Zelfs een programmeur test gemiddeld minstens 1 uur per uur code schrijven.
Idem pakketinrichting.
Hi Egbert, het lijkt er op dat er nog veel gedacht wordt (ook door jou in dit artikel…) vanuit het idee dat je test na ontwerp en bouw, in plaats van veel meer vooraf en tijdens ontwerp en bouw.
Als je vooraf en tijdens het ontwerpen en bouwen gaat testen, wordt de initiele investering veel minder groot, wordt het proces als geheel effectiever (minder rework!) en is het eigenlijk gewoon een kwaliteitscheck.