“Bezint eer ge begint met behulp van QuiST (Quick Scan Testkosten)”
Veel organisaties hebben het afgelopen decennium geïnvesteerd in het gestructureerd gaan testen van hun informatiesystemen. Op dit moment komt steeds vaker de vraag naar voren of het testen niet efficiënter en effectiever kan. De afgelopen jaren zijn er daarom methodes ontwikkeld om het testproces te verbeteren. De cruciale vraag die hierbij vaak onderbelicht blijft is: “Waar worden die hoge testkosten door veroorzaakt?” In dit artikel wordt ingegaan op deze cruciale vraag en wordt ingegaan op een analyse hulpmiddel om hier antwoord op te krijgen.
1. Inleiding
Het op een gestructureerde manier testen van informatiesystemen is de afgelopen jaren toegenomen. De reden hiervoor is dat organisatie de risico’s die zij lopen bij fouten in hun informatiesysteem zoveel mogelijk willen beperken. De vaak grote hoeveelheden fouten die worden gevonden tijdens testtrajecten bevestigen de toegevoegde waarde van (gestructureerd) testen. Wanneer echter binnen organisaties de vraag wordt gesteld “wat vindt u van het testproces?”, volgen steeds vaker de antwoorden “het duurt te lang” en “het is duur”. Organisaties gaan hoe langer hoe meer ervaren dat testen langer duurt dan in de oorspronkelijke planning was opgenomen en dat testen wel erg kostbaar is. Het eerste punt zorgt er vaak voor dat de in productie datum verschuift en dat daarmee de start van de Return of Investment later wordt en het tweede punt zorgt er voor dat de investeringen voor het ontwikkelen van een informatiesysteem hoog zijn. Vaak wordt 30-50% van de tijd die aan het ontwikkelen van een informatiesysteem wordt besteedt, besteedt aan systeem- en acceptatietesten. Veel organisaties ervaren op dit moment hogere percentages zoals 70%. Op zich is het dus niet gek dat organisaties vraagtekens gaan stellen bij de hoge kosten die gemoeid zijn met testen. De vraag naar een (nog) efficiënter en effectiever testproces is derhalve niet ongegrond. Binnen het testvak is hierop gereageerd door het enerzijds ontwikkelen van een methode voor het verbeteren van het testproces en anderzijds door meer de nadruk te gaan leggen op het gebruik van testtools. Uiteraard leidt dit tot een efficiënter en effectiever testproces. De vraag is echter of dit voldoende is en of er geen andere oplossingen mogelijk zijn? Voor een organisatie is het daarom van belang antwoord te krijgen op de volgende twee vragen:
- Is een inefficiënt testproces de (enige) oorzaak van de hoge kosten en de lange doorlooptijd of zijn er andere oorzaken aan te wijzen?
- Wat levert meer op: het verbeteren van het testproces of het weghalen van de andere oorzaken?
2. Mogelijke oorzaken
Er zijn twee gebieden te onderkennen als oorzaak van de (te) lange doorlooptijd en de (te) hoge kosten van het testen.
Het testproces zelf. Wanneer binnen het testtraject een aantal onderdelen niet goed wordt georganiseerd of uitgevoerd leidt dit vaak tot een moeizaam en onbeheersbaar verlopend proces. Testen duurt daardoor langer, kost veel meer dan begroot en levert weinig inzicht in de kwaliteit van het testproces en daarmee ook in de kwaliteit van het geteste informatiesysteem en de risico’s voor de bedrijfsvoering.
- Het ontbreken van een functioneel ontwerp heeft grote impact op de doorlooptijd en de kosten van het testproces. De testers moeten namelijk meer inspanning verrichten om de te testen functionaliteiten boven tafel te krijgen
- Het feit dat het oplossen van incidenten tot gevolg heeft dat er nieuwe incidenten ontstaan heeft ook direct consequenties voor het testproces. Het ontstaan van de nieuwe fouten wordt vaak veroorzaakt door ongestructureerd werken, onvoldoende inzicht in de samenhang tussen de diverse onderdelen van de software of onvoldoende inzicht in de samenhang van de functionaliteiten als gevolg van het ontbreken van het functioneel ontwerp. Voor de testers betekend dit meer hertesten dan verwacht en begroot.
- Het ontbreken van een goed configuratie management bij de ontwikkelaars kan ervoor zorgen dat testers met de verkeerde software werken of dat de ontwikkelaars fouten in de verkeerde versie van de software proberen op te lossen. De testers zijn dan meer tijd kwijt dan begroot omdat testen ten onrechte meerdere malen moeten worden uitgevoerd.
De modellen voor testprocesverbetering richten zich met name op het vaststellen van de huidige stand van zaken ten aanzien van het testproces. Inzicht in hoeverre de kwaliteit van het ontwikkeltraject invloed heeft op de te lange doorlooptijd en de te hoge kosten van het testen wordt door de modellen niet gegeven. Toch is dit inzicht van belang bij de afweging waar verbeteringen het meeste effect hebben op een kortere doorlooptijd en lagere kosten. In het IT-werkveld is dankzij de heer Boehm al jaren bekend dat hoe later in het ontwikkeltraject fouten worden ontdekt des te meer inspanning het kost om ze te herstellen.
Door het gestructureerd gaan testen is het moment van foutdetectie naar voren gehaald, namelijk van “Gebruik & Beheer” naar vlak na “Realisatie”. Dit heeft voor veel organisaties niet alleen de kosten voor foutherstel tijdens “Gebruik & Beheer” drastisch verlaagd, maar ook de kosten voor het wegnemen van vervolgschade is hierdoor afgenomen. Ondanks dit positieve resultaat blijft het moment van foutdetectie laat in het totale ontwikkeltraject plaats vinden en worden er gedurende het testen fouten ontdekt die eerder ontdekt hadden kunnen worden.
- Er kan vooraf niet inzichtelijk gemaakt worden wat de kosten/baten zijn van het toepassen van kwaliteitszorg;
- Het project kan niet wachten op goed uitgewerkte functionele specificaties omdat anders de technisch ontwerpers en programmeurs niets kunnen doen en dat kost tijd en geld;
-
Wanneer we aan kwaliteitszorg gaan doen krijgen we weer van die dikke, niet hanteerbare handboeken.
Het is niet aan de schrijver van dit artikel om een oordeel te vellen over deze argumenten. Wel vindt zij dat men dan wel de consequenties moet accepteren namelijk langere doorlooptijd en hogere kosten van het testtraject (en ook van het technisch ontwerp en de bouw). Wat namelijk gebeurt is dat een deel van de kosten van het voortraject komen te vallen binnen het testtraject. De als te hoog ervaren testkosten bevatten vaak oneigenlijke testkosten. Zou je deze oneigenlijke testkosten er uit halen dan zal voor veel organisaties blijken dat het testen relatief gezien helemaal niet zo duur is. Sterker nog je weet dan als organisatie ook wat de baten hadden kunnen zijn als je het voortraject beter had uitgevoerd.
3. QuiST als analyse hulpmiddel
Met het analyse hulpmiddel QuiST (Quick Scan Testkosten) worden op een snelle en inzichtelijke manier de knelpunten in het testtraject geanalyseerd en worden de oorzaken van de extra testkosten aangegeven. Naast de noodzakelijke testkosten wordt het effect van de interne en externe knelpunten op de totale testkosten zichtbaar gemaakt. Voor het beheersen van de testkosten bieden de resultaten van QuiST de onderbouwing om te kiezen voor het verbeteren van het ontwikkel- en/of testproces.
De methode Test Process Improvement (TPI) kan worden gebruikt als oplossingsrichting voor de interne knelpunten. Hiermee wordt de effectiviteit en efficiëntie van het testproces verbeterd en kan een kostenbesparing worden gerealiseerd. De externe knelpunten hebben te maken met de kwaliteit van het ontwikkelproces. De methode Kwaliteit-op-Maat (KoM) biedt de mogelijkheid om de kwaliteit van het ontwikkelproces en de geleverde producten te verbeteren en daarmee de test- en ontwikkelkosten te verlagen.
- Vaststellen te interviewen personen
In overleg met de opdrachtgever worden de te interviewen personen vastgesteld. De volgende functies kunnen bij het uitvoeren van QuiST betrokken worden: projectmanager, testmanager, systeemontwikkelaar en tester. - Invullen vragenlijst
Per betrokkene wordt een uur besteed aan het invullen van de vragenlijst met een ervaren testconsultant. Het invullen van de vragenlijst gebeurt met behulp van interviews. Dit om de testconsultant de gelegenheid te geven verdiepingsvragen te stellen. - Analyse testkosten
De testconsultant analyseert de antwoorden en de eventueel ontvangen projectdocumentatie. - Opstellen rapport QuiST
Op basis van de analyseresultaten stelt de testconsultant een rapportage op met de volgende onderwerpen
- Achtergrond informatie
- Knelpunten
- Bevindingen
- Consequenties
- Conclusies
- Aanbevelingen
Filed under: Testprocesverbetering | getagged: belang van testen, KoM, Kwaliteit op Maat, Testprocesverbetering, TMap, TMap Next, TMMI, TPI
