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).
Ewald heeft zeker gelijk!!
In principe is juist wat de heer Rodenrijs stelt. Waarom wordt er dan niet veel meer getoetst (gereviewd)?
Toetsen kun je individueel of groepsgewijs doen.
Groepsgewijs heeft voordelen: een opmerking van de een triggert een opmerking van een ander, de reviewers houden elkaar bij de les en de bevindingen staan in een overzichtelijke lijst.
Het grote nadeel is dat voor een groepsgewijze review een meeting moet worden georganiseerd. Op het moment dat het document klaar is kan het een week of langer duren voor alle reviewers tegelijk een gaatje in hun agenda vrij hebben om aan de review deel te nemen.
Dan maar individueel, want dan kunnen de reviewers reviewen wanneer het hun schikt. Kent u dat? Na de lunch met een bekertje koffie in de hand, de voeten op het bureau, even dat document reviewen. “Ja, dat is wel ongeveer wat we bedoelden.” De wat serieuzere reviewers melden allen dezelfde opvallende fouten, de wat diepere blijven liggen. De auteur krijgt bevindingen op allerlei manieren terug: met de hand in een afdruk geschreven, in het tekstbestand erbij gezet, in een excel-bestand, enzovoort. Probeer die maar eens systematisch af te handelen.
Is het gek dat men liever geen reviews doet?
Ewald heeft gelijk, als in een eerder stadium bevindigen kunnen voorkomen zal dit zeker kostenbesparend zijn als er meerdere bevindingen aan het eind gevonden worden. Echter toetsen is zeker een onderdeel van het testproces. Als testmanager zal je samen met de organisatie in het begin van het project toetsen of alle documentatie aanwezig zijn, zijn deze gereviewd. Je toetst / test of de beschreven requirements daadwerkelijk vertaald zijn in je technisch – en functioneel ontwerp. Deze documenten zijn de basis om de testgevallen c.q. testscripts op te stellen. Met de titel is toetsen minder testen ben ik het niet eens want toetsen = testen.
Toetsen is zeker een manier om de curve van Boehm te tackelen. De kern van die problematiek is dat lang duurt voordat de fout gevonden wordt. De feedback loop is dus te lang; als je die korter maakt wordt het herstel van de fout goedkoper.
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.
De denkfout die aan diie “dure fouten” ten grondslag ligt is dat je alle activiteiten gegroepeerd bij elkaar voor het hele systeem uitvoert. Door de activiteiten juist kort na elkaar uit te voeren voor een deel van de functionaliteit, tackel je de curve van Boehm.
Wilcor, ik ben het inderdaad met Ewald eens, veel mensen maken onderscheid tussen testen en toetsen. Als je het goed bekijkt: testen = testen + toetsen. Ik denk dat Ewald het zo bedoelt. Zien alle klanten testen maar als testen en toetsen 😉
Het had wellicht geholpen als in het artikel uitgelegd werd wat onder “toetsen” verstaan wordt.
Er vanuit gaande dat het “reviewen” is, zoals Karel opmerkt, dan is toetsen eigenlijk gewoon een vorm van testen
peer-review van designdocumenttatie, en code-review voordat er gecompileerd wordt zijn vormen van verificatie, net zoals testen dat kan zijn
Helemaal eens met Ewald! Toetsen loont!
Of toetsen testen is of andersom is een definitie kwestie. Persoonlijk vind ik dat niet zo interessant. Wat veel interessanter is, is het antwoord op de vraag van Karel van Zanten: als het dan zo goed is, waarom doen we dat niet veel meer?
Uiteraard heeft hij gelijk, een review met je voeten op het bureau gaat niet echt helpen. Maar serieus toetsen d.m.v. reviews, inspecties en walkthroughs doet dat wel!! Maar waarom doen we dat dan zo weinig? Ten eerste omdat we altijd haast hebben, denk ik. Veel projectmanagers willen zo snel mogelijk starten. Requirements staan op papier, dus bouwen!! Goede ontwerpen maken, de tijd nemen om ze te reviewen/inspecteren/etc. is er niet. Jammer, want 70% van de gemaakte fouten zit in die documentatie. En als je daar dan de curve van Boehm op loslaat, dan is het toch niet zo moeilijk om uit te rekenen hoeveel je zou kunnen besparen?
Maar veel organisaties hebben blijkbaar voldoende beheer capaciteit (kosten in de lijn, dus niet voor het project) of gebruikers die testen (opnieuw kosten in de lijn). Toetsen kost geld en dat is dan weer wel projectbudget!
En ten tweede omdat het moeilijk is! Een goede inspectie vergt training! Review sessies organiseer je niet zo maar! Een goede moderator ben je niet na een training van een dag. Voor een heel project moet je dan ook nog eens nadenken welke toets techniek je waar gaat toepassen…
Anko heeft ook gelijk, die curve is ook prima aan te vallen met Agile werkwijze. Maar als je organisatie (nog) niet Agile werkt, is toetsen een prima optie!
Daarbij wil ik ook nog even opmerken dat toetsen niet “alleen” testen is… De projectmanager is mede verantwoordelijk om het toetsproces vroegtijdig in te richten. Het gaat dus veel verder als testen. De PM is tenslotte verantwoordelijk voor de documentatie. Alle documentatie! En die zou ik dus ook allemaal willen toetsen. Niet alles even zwaar, dus een toets strategie, is dan een handig hulpmiddel! Ik wil hem daar als testmanager natuurlijk graag bij helpen.
Dus kort samengevat: alle documenten toetsen of een Agile aanpak! En ja: door te toetsen, zul je uiteindelijk minder hoeven testen (denk vooral aan hertesten, etc.)
Ewald heeft het goed! Toetsen en testen vallen beide onder het brede Testen. Het heet niet voor niets statisch en dynamisch testen. Wat ik nu wel mis in het verhaal dat je niet “blind” maximaal gaat toetsen en testen, maar dit doet op basis van risico’s. Wie weet beslis je wel dat de risico’s zo groot zijn dat je test-driven gaat ontwikkelen. M.a.w. eerst de specificaties schrijven, dan toetsen en vervolgens de testen (scripts)uitschrijven. Op basis daarvan gaat er gebouwd worden. Overigens ben ik van mening dat ontwikkelmethodieken als Agile en RUP die gezien worden als de oplossing slechts een masker zijn voor de uren die je spendeert. Nogmaals het efficient inzetten van toetsen en testen is en blijft de basis.
@CK: Kun je je mening ergens mee onderbouwen? (dat ontwikkelmethodieken als Agile en RUP slechts een masker zijn).
Eigenlijk hoef je geen woorden meer vuil te maken aan het nut van een goede review. Wat voor soort review dan ook, hij is altijd nuttig.
Het werd al eerder genoemd: Hoe vaak zie je het inderdaad niet: “documentje erbij, voetjes op de tafel, bakkie erbij, en het hele documentje van begin tot eind doornemen”.
Helaas mis ik bij alle review(sessie)s altijd nog 1 ding: Risicogebaseerd reviewen. Je kent het ook wel tijdens zo’n koffie-review. Aan het eind verslapt de aandacht… oh, daar zat nou net het belangrijkste stuk. Jammerrr… Echter, we stellen met een PRA een overzicht van geprioriteerde risico’s op. Waarom hanteren we die dan ook niet bij deze reviews? Als de tijd om te reviewen dan toch zo kort is, waarom pakken we dan net zoals met alle overige testzaken de belangrijkste zaken niet eerst? Als de tijd op is, hebben we in ieder geval de belangrijkste stukken eerst gereviewd.
Het bovenstaande kun je natuurlijk ook verder doortrekken naar bijvoorbeeld het opzetten van het ontwerp zelf. Want het komt ook maar vaak zat voor dat het belangrijkste/lastigste/meest complexe deel van het ontwerp ook pas later opgeleverd wordt.