Kwaliteitszorg wordt door organisaties gezien als een kostenpost, echter bij doelgericht gebruik verlaagt het de ontwikkelkosten! Hoe kan een organisatie nu de kosten voor kwaliteitszorg zo laag mogelijk houden en toch een zo hoog mogelijk kwaliteitsniveau halen? Eén antwoord daarop is toetsen! Toetsen is een kwaliteitszorgmaatregel welke vanaf de start van een project ingezet kan worden om de kwaliteit van het eindproduct zo hoog mogelijk te houden.
Vanuit het kostenperspectief heeft een klant maar één vraag: wat levert toetsen me op? Want toetsen lijkt een dure maatregel. De klant moet investeren in nog meer werk, nog meer activiteiten, hetgeen de werkzaamheden (en dus de deadline) alleen maar lijkt op te houden. Om deze vraag te beantwoorden is het nodig de baten van de investering onomstotelijk aan te tonen, voordat ze gerealiseerd zijn. In de loop der jaren is veel onderzoek gedaan naar het effect van toetsen op het totale ontwikkelproces. Hiermee is een goede onderbouwing van de baten te geven.
Al in 1979 heeft Boehm onderzoek gedaan naar de herstelkosten. Zijn uitkomst was dat de herstelkosten oplopen naarmate ze later in het ontwikkelproces zijn gemaakt. Dus, een fout vroeg in het ontwikkelproces oplossen is goedkoper dan later. Boehm (en later Gilb) stelt dat een fout uit een ontwerp halen zestien keer zo goedkoop is als het herstellen van dezelfde fout in de testfase.
De klant heeft dus veel voordeel bij de preventie of correctie van gevonden fouten vroeg in het ontwikkelproces. Op deze manier blijven de faal- en herstelkosten lager. Zolang de kwaliteits- en preventiekosten minder kosten dan de verwachte herstelkosten zonder invoering van deze maatregelen, levert dat overall een kostenbesparing op. Een serieus uitgevoerd foutdetectieproces kan in één toetsronde 88 procent van de significante fouten vinden in een document. Fouten die tijdens het testproces niet meer worden gevonden en ook in de software niet meer worden hersteld! Zodoende komen er minder bevindingen op de software en elke bevinding kost ongeveer derig minuten testtijd bij handmatig testen. Gevolg is een snellere testuitvoering per testronde en minder testronden om de software te testen.
Door toetsen stijgen wel de kosten vroeg in het project, zonder dat daar op korte termijn resultaten mee behaald worden. Op de langere termijn terugverdienen gebeurt echter weer wel tijdens het testen. Door het goed toepassen van verschillende toets- en leestechnieken is het mogelijk de kosten op korte termijn te beperken. In een toetsstrategie wordt per risicogebied en type document bepaald hoe wordt getoetst. Door gebruik te maken van de juiste technieken en een toetstrategie is het mogelijk het toetsproces te optimaliseen. Zodoende ontstaat niet alleen een beter resultaat, ook gebeurt het toetsproces efficiënter (en tegen lagere kosten).
Toch wel grappig dat iedereen plotseling roemt over het feit dat vroegtijdig controleren (of je het nou toetsen of testen noemt) van documenten loont, terwijl bijna niemand dit principe toepast.
De Agilisten passen dit principes het vaakst toe omdat de methodiek dit afdwingt.
@Gerard
Een methodiek die iets afdwingt is a absoluut geen garantie voor het succesvol toepassen!!!
Het staat of valt met de mensen. Tussen reviewen en reviewen zit een groot verschil. De laatste tijd zie ik steeds vaker documenten van belabberde kwaliteit voorbij komen, die dan gereviewed zijn om het proces te bevredigen. Inhoudelijk laat de kwaliteit van de review te wensen over.
Hier helpt geen Agile, of welke andere methodiek dan ook, aan!!!
Ik ben het helemaal eens met Ewald: Toetsen van producten is essentieel voor het leveren van kwaliteit:
Het W-model moet meer worden toegepast dan het V-model.
Om inzicht te geven in de toegevoegde waarde van toetsen voor de klant zijn de volgende punten o.a van belang om mee te nemen in de toeststrategie van een organisatie:
A)
Medewerkers en managment dienen intensief te worden betrokken bij de inrichting van de toetstrategie;
B)
Return on investment indicatoren dienen aan te tonen aan medewerkers en management van het economisch nut van toetsen, ic metrieken ter beheersing van het toetsproces en productkwaliteit kunnen de toegevoegde waarde aan tonen van het toetsproces.
C)
Het geven van cursussen op het gebied van toetsen aan medewerkers.
D)
Het aanwijzen van een ‘Champion’ binnen de organisatie. Deze persoon zou de taak moeten krijgen om medewerkers te motiveren en al wat niet meer nodig is om toetsen (reviewen en inspecteren) verankerd te krijgen binnen het ontwikkelproces.
Anko schrhijft:
“Dit principe vind je terug in agile projecten: per iteratie vindt er een acceptatietest en een demo plaats. Dat betekent dat al in een relatief korte periode dergelijke “dure fouten” (die in een regulier traject laat worden gevonden) worden geconstateerd.”
Dit is niet het principe van toetsen maar dat van “heel kleine projectjes”. En dan geldt nog steeds dat, wanneer de fout gevonden wordt bij de acceptatietest of de demo, dat een dure fout is die “achterin de curve van Boehm” zit.
It still surprises me how evaluation and quality assurance gets deprioritised in budget decisions. Totally agree that an inegrated evaluation approach right from the start of a project will be more efficient. Won’t necessarily translate to less testing time per se, but definitely to less testing for defects.
In practice, having an integrated evaluation approach has a lot to do with both the project methodology and internal processes in place. The process should help the project run smoother, not hinder the dynamics. Orgs should be clear with what exactly review processes involve in terms of time and resources and overall project development. And a step back would actually be to determine what is quality in the firs place. A clear set of accpetance criteria should be identified and agreed by the parties involved. There are lots of cases when too many stakeholders or reviewers get involved in the whole evauation process that it deters progress rather than facilitate it.
I personally like the agile methodology as testing/evauatio/acceptance criteria is a basic principle and approach to developing and running the project. Evaluation is not a by-product but a required function not just by a tester but by other team members, esp the product owner / business analyst and developers.
reactie op stelling van Chris Schotanus:
Ik praat over iteraties van max 4 weken en het feit dat een systeem in meerdere iteraties wordt gebouwd. Iedere iteratie kent een acceptatietest en die vindt al tijdens de iteratie plaats. Dus binnen 4 weken wordt de fout geconstateerd en hersteld. Daarbij leert het team en worden er gedurende het proces steeds minder voorkoombare fouten gemaakt.
Wat volgens mij aan de curve van Boehm ten grondslag ligt is dat rework duur is. Als je dus je rework weet te beperken (door een proces met veel feedback toe te passen -zoals agile-) ben je goedkoper uit.