Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Is meer toetsen minder testen?

 

Computable Expert

Ewald Roodenrijs B ICT
Test Manager, Cognizant Benelux BV. Expert van Computable voor de topics Digital Transformation, Development en Cloud Computing.

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).

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3026966). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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.

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 zeker gelijk!!

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.

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.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×