Het bezuinigen op testen van software voordat deze 'ín productie' wordt genomen roept vraagtekens op. De gevolgen kunnen meer schade berokkenen dat de vermeende besparing doet vermoeden. De investering in testen wordt snel terugverdiend omdat de helpdesk minder belast wordt. Daarnaast raakt de gebruiker minder snel geïrriteerd en gefrustreerd en wordt het imago van de leverancier er alleen maar beter van.
De kosten van een probleem kunnen wel oplopen tot een factor honderd (Boehm 1981, Grady, 1999; NIST, 2002) als deze in de software zit en de gebruikers er mee werken. Waarschijnlijk is er een helpdesk waar de gebruikers naar toe kunnen bellen voor problemen. Vaak is er een standaard antwoord dat terug te vinden is in de beschikbare kennisdatabase. Dit is vaak voldoende om het probleem van de gebruiker op te lossen. Dit werkt efficiënt en effectief en de helpdesk medewerkers communiceren de lopende problemen met de ontwikkel organisatie. De ontwikkelaars lossen de problemen op en voeren een upgrade uit op de software bij de gebruiker en de problemen zijn opgelost.
Dan ontstaan echter weer nieuwe problemen bij de gebruiker. De eerste keer zal de helpdesk het probleem nog moeten analyseren en rapporteren. En na een paar keer zal dit nieuwe probleem ook weer in de kennisdatabase staan, waarna de helpdesk de gebruikers kunnen helpen.
Kosten
Een probleem wat in het ontwerp wordt gevonden kost zo'n honderd euro. Mocht het probleem in het ontwerp blijven – een programmeur programmeert dit in de software en de testafdeling ziet dit probleem ook niet – dan kost dit probleem duizend tot achttienhonderd euro in productie.
Waarschijnlijk komt dit verhaal bekend voor en is er een testafdeling die controleert of software goed genoeg is voor productie. Het testen van software kan opleveren dat het probleem al bekend is bij de helpdesk en dat het scenario of de workaround al klaar ligt bij de helpdesk. Dit scheelt uitzoekwerk van een paar mensen van de helpdesk. Hiermee worden kostbare euro's bespaard.
Verborgen besparingen
Testen de ontwerpers hun eigen ontwerpen? Vast wel. De ontwerpen worden naar collega's gestuurd en deze reviewen het werk van elkaar. Misschien bespaar je hiermee wel tien problemen per ontwerp, dus (tienduizend min duizend) negenduizend euro.
Controleren programmeurs de programma code door deze te reviewen, testen programmeurs hun werk, nemen ze adviezen aan van de testafdeling? Elk probleem wordt opgelost voor tweehonderd euro per probleem, dus voor tien problemen een besparing van ongeveer (tienduizend min tweeduizend) achtduizend euro.
De testafdeling vergelijkt de ontwerpen met de geleverde software en in een productie-like omgeving en vindt hier ook weer tien problemen, die opgelost worden door de programmeurs en ontwerpen worden hier en daar aangepast. Voor tien problemen bespaart je dan (tienduizend min zesduizend) vierduizend euro.
Met kwaliteitscontroles op deze niveaus wordt in dit hypothetische geval (negenduizend plus achtduizend plus vierduizend) 21.000 euro bespaard. Je bespaart daarnaastimago schade, of een mooi verhaal in de pers (Telegraaf, Computable). Dit is wat moeilijker in geld uit te drukken en na bovenstaand verhaal met de fictieve bedragen waag ik mij daar ook niet aan.
Het gaat meer om het feit dat deze kosten bij veel organisaties onder de 'verborgen kosten' vallen. Het budget van een project rekent bijvoorbeeld geen budget van de helpdesk mee. Dus alle problemen die buiten het project gehouden kunnen worden en later opgelost, vallen straks in het 'service level agreement'-budget, in het Nederlands 'service niveau overeenkomst, sno of snow als je het uitspreekt. Sneeuw smelt, uw budget ook.
Meten = weten, actie = resultaat
Als je naast de registratie van bevindingen en helpdesk-calls de kosten gaat noteren, dan weet je wat een probleem de organisatie kost en aan de hand daarvan kun je verbeteringen doorvoeren in de kwaliteit van deze producten. Je kunt ook gelijk beginnen met de volgende simpele verbeteringen die direct tot resultaat leiden:
– Hou formele reviewsessies met de ontwerpers, voorgezeten door een testmanager.
– Hou product risico analyses in een vroegtijdig stadium, zodat iedereen zich bewust wordt van mogelijke problemen en er van te voren hiermee bezig is.
– Geef trainingen aan programmeurs hoe om te gaan met unit testen/ontwikkeltesten.
– Zorg voor voldoende testtools voor de programmeurs.
– Neem personeel in dienst die de ontwerpers en programmeurs kunnen begeleiden met deze controles.
Conclusie
Besparen op kwaliteit controles door de slechte financiële markt of tijdsdruk? Het snel kunnen upgraden van je software bij de gebruiker? Niet zichtbaar maken wat problemen nu werkelijk kosten? Dit alles maakt het product straks duurder dan dat van de concurrentie, terwijlje zeker duizend euro per probleem bespaart als je meer nadruk legt op de kwaliteitscontroles tijdens het gehele ontwikkelproces.
Dus niet besparen op testen, maar inzichtelijk maken en investeren, zeker in deze markt waar de concurrentie groot is en de gebruiker bewust is van kwaliteit en mondig is geworden. En de pers luistert ook mee.
Heb je ontwerp reviews, code reviews, ontwikkeltesten, systeem- en gebruikerstesten al deel gemaakt van het standaard proces? Dan kun je gaan werken aan het efficiënter maken door bijvoorbeeld te kijken of je al aan automatisch testen kan beginnen. Maar tot aan dit punt: Blijven investeren in kwaliteit, dat levert alleen maar winst op.
Rob van Steenbergen, directeur Chickenwings Test Consultancy
Heel snel wordt al weer gewezen naar geautomatiseerd testen. Ik vind dat meestal wel een erg makkelijke kijk. Testen wordt vaak onderschat. Als tester hoor je ook mee te denken en na te denken over wat de klant wil en wat smart is. De ervaren tester is vaak smart. Dat valt meestal niet te automatiseren. Als het gewoon om simpele handelingen en dus simpele testen gaat, dan moet je juist voor geautomatiseerd testen gaan. Want dat is gewoonweg dom werk en zeker niet motiverend.
Wil je besparen in testtijd, maak dan het testen smart en minder rigide (maak bv betere keuzes voor testgevallen en laat mindere belangrijke vallen), dit kan natuurlijk wel meer risico inhouden. Huur ervaren krachten in, die de doorlooptijd verkorten en dus uiteidelijk goedkoper zijn.
Uitvoerend testen = Inhoudelijke kennis, Test Ervaring, Mentaliteit/Motivatie en Specificaties gebruiken.
Als alleen de specificatie gebruikt zouden worden, dan kun je makkelijk automatiseren. Echter de andere factoren wegen zwaarder als men denkt en worden te vaak vergeten.
Het is inderdaad belangrijk om de kosten van niet testen in scope te hebben. Maar het is wel belangrijk om te kijken naar zowel de preventiekosten, als de herstelkosten. Indien de herstelkosten juist lager zijn dan de preventiekosten gaat je verhaal niet op.
Over het algemeen loont het zeker om zo snel mogelijk kosten te besparen. Dat komt overeen met jouw opmerking t.a.v. de formele reviewsessies met de ontwerpers. De klant heeft het meeste voordeel bij preventie of correctie van fouten die vroeg in het ontwikkelproces zijn gevonden. Op die manier blijven de faal- en herstelkosten het laagst. Een gestructureerd uitgevoerd foutdetectieproces (Toetsen) kan in één toetsronde 88% van de significante fouten opleveren in een document, en dus voorkomen in het toekomstige eindproduct. Dit kan, evenals een teststrategie, in een toetsstrategie worden verwerkt.
Door binnen de toetsstrategie te kijken naar niet alleen de kosten, maar ook het resultaat, de risico’s en de doorlooptijd kan juist worden bepaald welke stappen nodig zijn om een product uiteindelijk zo goed mogelijk op te leveren. Dit is Business Driven Test Management (BDTM). Een testmanager richt zich daarbij ook niet meer alleen op testen, maar wordt steeds vroeger betrokken in het project en richt zich dus ook op het toetsen van de documentatie.
Bijkomend voordeel is dat deze niet alleen niet meer voorkomen na in-productie-name, maar ook in bijvoorbeeld het testproces. Fouten die tijdens het testproces niet meer worden gevonden en ook in de software niet meer hoeven te worden hersteld! Zodoende komen er minder bevindingen op de software en elke bevinding kost ca. 30 minuten testtijd bij handmatig testen. Gevolg is een snellere testuitvoering per testronde en minder testronden om de software te testen.
Het slim toepassen van een goede toetsstrategie maakt het mogelijk om zoveel mogelijk fouten te vinden. Dus een betere kwaliteitscontrole levert niet alleen kostenbesparing op, maar ook tijdswinst!
Bezuinigen op het testproces is inderdaad een kwalijke zaak wanneer de kwaliteit van de producten die we in het testproces stoppen (de testbasis) onvoldoende zijn. Zoals aangegeven is toetsen inderdaad een methode om te zorgen voor een verhoogde kwaliteit van deze testbasis. In de praktijk blijkt het helaas vaak nodig dat de testmanager het toetsproces moet initiëren om op deze manier in ieder geval de minimale kwaliteit te behalen van de testbasis.
Echter, als we kijken naar bijvoorbeeld het functioneel ontwerp, dan is het niet alleen een testteam die dit product gebruikt om te testen maar hebben ontwikkelaars dit ook nodig om het product te bouwen en eventuele technische ontwerpen op te stellen. Om de kwaliteit van alle essentiële producten voor alle betrokken partijen te waarborgen moet het toetsproces niet door een testmanager aangestuurd worden maar ligt deze verantwoordelijkheid bij een projectmanager of, bij voorkeur, bij een kwaliteitsmanager.
Deze kwaliteitsmanager zorgt ervoor dat alle stakeholders van een product betrokken zijn bij het toetsen van dit product, zorgt ervoor dat het product zo vroeg mogelijk getoetst kan worden, en zorgt ervoor dat de mensen met de juiste kennis worden uitgenodigd om deel te nemen aan de toetssessie. Dit alles wordt door een kwaliteitsmanager samengevat in een toetsstrategie, welke bijvoorbeeld opgenomen kan worden in een kwaliteitsplan.
De kwaliteitsmanager moet ook zorgen dat de juiste toetstechnieken gebruikt worden. Een collegiale review voor een essentieel functioneel ontwerp zal waarschijnlijk niet voldoende zijn en een audit laten plaatsvinden op een voortgangsrapportage is ook overdreven. De kwaliteitsmanager zorgt dat een balans blijft bestaan tussen tijd, geld en kwaliteit door middel van risk based toetsen.
De toets mag niet te lang duren (efficiënt en effectief sessies uitvoeren). De toets mag niet teveel geld kosten (niet het hele project laten deelnemen aan de review maar alleen de mensen met relevante kennis). En de toets moet het goede resultaat opleveren (alle stakeholders moeten het product goed genoeg vinden). Verder gaan we niet alle producten toetsen maar gaan we keuzes maken. Bijvoorbeeld: een functioneel ontwerp wordt wel formeel getoetst maar een voortgangsrapportage niet.
Conclusie:
Risk based toetsen leidt tot een verhoogde kwaliteit van de producten, en dus ook de testbasis. Hierdoor hoeft niet bezuinigd te worden op het testproces want dit zal dan automatisch beter en sneller lopen omdat veel bevindingen niet meer op de testbasis worden gedaan. Dus betere kwaliteit en tijdwinst!
Dus: de juiste mensen met de juiste kennis gaan kijken naar de juiste producten op het juiste tijdstip.
Arno schrijft:
>
Conclusie:
Risk based toetsen leidt tot een verhoogde kwaliteit van de producten, en dus ook de testbasis. Hierdoor hoeft niet bezuinigd te worden op het testproces want dit zal dan automatisch beter en sneller lopen omdat veel bevindingen niet meer op de testbasis worden gedaan. Dus betere kwaliteit en tijdwinst!
< Ik vind dat wat kort door de bocht en erg ongenuanceerd. Risk based toetsen KAN leiden tot een verhoogde kwaliteit. Het kan er ook toe leiden dat je van je high risk tussenproducten vaststelt dat ze al goed zijn, en daardoor de illusie kweken dat alle documentatie goed is. Daarnaast kan kwaliteit tijdwinst opleveren. Dat hoeft niet. Moet je gewoon meten. Maar wil je wel tijdwinst? Meestal gaat het om een bijdrage aan de primaire processen, en dat is bedrijfswinst...
Laten we wel even bij de feiten blijven.
Testen kost geld. Het levert NOOIT geld op. Besparen door niet te testen is nog geen winst maken. Je maakt nog steeds verlies. Feitelijk is productontwikkeling, waar ook testen onder valt, een verliespost. Pas als deze investering terugverdiend is, wordt er winst gegenereerd. Door niet te testen heb je een verlies op korte termijn mogelijk gereduceerd. Het grote nadeel van niet testen is dat je het inzicht kwijt bent in de kwaliteit en je feitelijk dus niet kunt inschatten hoeveel er op lange termijn terugverdient moet gaan worden om winst te gaan genereren. Je hebt dus minder inzicht in de verliespost voor de gehele product life-cycle en komt er in een laat stadium pas achter of de baten van de productontwikkeling opwegen tegen de kosten. Door WEL te testen krijg je vroeger inzicht in de kosten van productontwikkeling en kun je deze MOGELIJK op korte termijn REDUCEREN. Ook met testen blijft het nog steeds een kunst om te berekenen hoe en of deze productontwikkeling verliezen goedgemaakt kunnen worden in de winst door middel van bijv. het inzetten van de applicatie. Maar je hebt nu in ieder geval meer meetpunten. Je kunt nu in een vroeger stadium een nauwkeurigere inschatting doen in kostenposten, waardoor de terugverdientijd ook nauwkeuriger wordt.
Ook voegt testen geen kwaliteit toe. Testen biedt INZICHT in de kwaliteit en is een van de handvatten om vroegtijd de kostenpost van een product life-cycle inzichtelijk te maken. Maar zolang een constatering niet opgelost wordt, blijft de kwaliteit gelijk.