Testen aan de voorkant

testen als kritische succesfactor

t

Testen aan de voorkant

Optimaal

De meeste organisaties zien testen als noodzakelijke en effectieve

rendement halen

maatregel om de kwaliteit van systemen te bepalen en fouten

uit reviews

eruit te halen voordat ze in productie gaan. Het is echter niet altijd efficiënt. Veel van de gevonden fouten in tests zijn vroeg in het ontwikkeltraject gemaakt, wat tot onnodig hoge reworkkosten leidt. Steeds meer organisaties voeren daarom reviews uit waarmee die fouten veel eerder worden gevonden. Er zijn echter nog weinig organisaties die optimaal rendement halen uit reviews.

informatie / december 2009

Jan Jaap Cannegieter en Mark van der Zwan

28

De afgelopen jaren heeft testen een vaste, onbetwiste plaats veroverd in ontwikkeltrajecten. Testen is bij veel organisaties een activiteit die vroeg in het ontwikkeltraject begint met het opstellen van een teststrategie en het opstellen van testcases. Het is bij veel organisaties niet iets wat de bouwers nog even snel na de ontwikkeling doen. De redenen hiervoor zijn duidelijk. De samenhang van systemen is zo complex dat fouten met grote gevolgen snel gemaakt worden. Daarnaast neemt het belang van goede systemen zienderogen toe. Veel organisaties zijn erachter gekomen dat testen een vak is. De meeste testtrajecten bestaan ook uit meerdere testsoorten met allemaal hun eigen doel en toegevoegde waarde. Vaak wordt dit samengevat in het zogenaamde V-model (zie figuur 1). De kwaliteit van systemen is inzichtelijk en systemen gaan met minder fouten in productie. Toch is dat niet helemaal waar. Uit onderzoek blijkt namelijk dat veel van de fouten gevonden in tests eerder hadden kunnen worden gevonden. Dat ze pas in een latere fase worden gevonden,

brengt hoge kosten met zich mee. Het blijkt dat (Standish Group, 2006; Jones, 2000): • 60 procent van de fouten komt door onjuiste/ onduidelijke requirements; • 80 procent van de fouten kan eerder worden gevonden dan pas tijdens het testen; • 40 tot 60 procent van de projectkosten worden veroorzaakt door rework. Dit sluit aan op onze praktijkervaring. Veel projecten lopen uit in de testfase en de vraag rijst dan of het testen niet goedkoper kan. De uitloop bij het testen wordt echter veroorzaakt door de vele fouten die in het systeem zitten! Niet het testen op zich maar het feit dat er veel fouten in het systeem zitten maakt testen tijdrovend. Als deze fouten eerder worden gevonden, wordt de uitloop in de testfase vanzelf minder en worden hoge kosten en onverwachte uitloop voorkomen. Steeds meer organisaties realiseren zich dit. Daarnaast staat in zo ongeveer elke methode dat reviews een belangrijk onderdeel zijn van de projectvoering. Voorbeelden van dergelijke methoden zijn RUP, PRINCE2, CMMI voor ontwikkeling en CMMI

Samenvatting Door het professioneel uitvoeren van reviews kunnen onnodige reworkkosten en onnodige uitloop worden voorkomen. Het op professionele wijze uitvoeren van reviews op zichzelf levert al veel op. Door de fouten die gevonden worden tijdens de reviews te evalueren neemt de toegevoegde waarde van reviews nog verder toe. Op die manier worden projecten op lange termijn nog goedkoper, sneller en succesvoller.

V-model wordt W-model Het concept van reviews is eenvoudig: je laat één of enkele medewerkers die het product niet hebben gemaakt het product beoordelen, eventueel op basis van een referentiekader of uitgangsdocument waaraan het product dient te voldoen. Het product kan een document zijn, maar kan ook heel goed code, een databaseontwerp of een interfacebeschrijving en dergelijke zijn. Figuur 2 geeft de essentie van een review weer. Reviewen is meer dan een document op het bureau van een collega gooien en vragen of die collega het even wil lezen en de opmerkingen

wens

werkelijkheid

acceptatietest

requirements

functioneel ontwerp

systeemtest & ketentest

technisch ontwerp

realisatie

integratietest

programmatest

Figuur 1. V-model

terug wil koppelen. Bij een belangrijk tussenproduct kan worden gekozen voor een formelere en uitgebreidere vorm van reviewen. Enkele kenmerken van professionele reviews zijn: • Er is voldoende tijd gereserveerd voor de reviews. • Er zijn meerdere reviewers met allemaal een andere achtergrond. • Er wordt een reviewstrategie opgesteld waarbij iedere reviewer naar andere fouten op zoek gaat. • Bevindingen worden gestructureerd vastgelegd. • De review wordt begeleid door een ervaren moderator. • De review wordt uitgevoerd aan de hand van checklists of uitgangsdocumentatie waaraan het te reviewen product moet voldoen. • De voordelen van reviews worden bepaald en gerapporteerd. Eventueel worden ook andere metrieken opgesteld. Door de reviews op te nemen in het V-model ontstaat een beeld wanneer welke review wordt uitgevoerd. Dan ontstaat het zogenaamde W-model; een voorbeeld hiervan is opgenomen in figuur 3.

Optimaal rendement Het zou fantastisch zijn als fouten eerder werden gevonden, het testen minder uitloopt, de communicatie beter verloopt et cetera. Iedereen blij? Ja, mits reviews op professionele wijze worden uitgevoerd. Maar toch is het verhaal nog niet uit. Reviews leveren namelijk informatie op waarmee organisaties hun werkwijze fundamenteel kunnen verbeteren. Het vinden en herstellen van fouten levert eenmalig voor het project al de nodige voordelen op, het voorkomen van fouten door ze te analyseren en de oorzaak weg te nemen levert voor alle toekomstige projecten nog veel meer op. Dit wordt preventie genoemd. De essentie van preventie is opgenomen in figuur 4, die een uitbreiding is van figuur 2.


voor acquisitie. Om nog even bij de laatste stil te staan: vooral bij het beheersen van uitbesteding en goed opdrachtgeverschap worden reviews als essentieel gezien.

29


t

Onder het motto ‘voorkomen is beter dan genezen’ kan de toegevoegde waarde van reviews nog veel hoger zijn. Veel verbetertrajecten worden gebaseerd op het geloof dat een bepaalde methode toegevoegde waarde heeft voor een organisatie. Door verbeteringen door te voeren op basis van analyses waar en wanneer de meeste fouten zijn gemaakt, neemt het commitment van management en medewerkers zienderogen toe. Het is immers duidelijk welke problemen worden opgelost.

Preventie Preventie van fouten kan op twee niveaus plaatsvinden: op persoonlijk niveau en op organisatieniveau. Bij preventie op persoonlijk niveau analyseert de maker van het product dat gereviewd is de bevindingen en probeert hij of zij voor zichzelf te achterhalen hoe de fout heeft kunnen ontstaan: Ontbrak bepaalde informatie? Mis ik bepaalde kennis of vaardigheden? Was de input waarop ik mijn werk gebaseerd heb van voldoende niveau? Uit deze analyse kunnen persoonlijke verbeterdoelstellingen naar voren komen. Door bij een volgende review vast te stellen of dezelfde fouten nogmaals gemaakt zijn, kan de medewerker vaststellen of de persoonlijke werkwijze daadwerkelijk is verbeterd. Deze vorm van preventie lijkt een heel individueel proces. Om preventie op persoonlijk niveau meer te structureren en er het optimale rendement uit te halen kan een medewerker

review

conceptproduct

project

Figuur 2. Essentie van reviews

begeleid worden door een coach. Uit de praktijk blijkt dat het effect van preventie op persoonlijk niveau aanzienlijk hoger is als de medewerker door een coach wordt begeleid. Preventie op organisatieniveau wordt causale analyse genoemd. De doelen van causale analyse zijn het achterhalen van de oorzaak in de werkwijze van de organisatie en het formuleren van procesverbetervoorstellen om deze oorzaak weg te nemen. De achterliggende doelstelling is om ervoor te zorgen dat dezelfde fout niet nog een keer wordt gemaakt of dat die fout eerder wordt gevonden. De causale analyse bestaat uit drie stappen, zoals weergegeven in figuur 5. De input van de causale analyse zijn de fouten, bijvoorbeeld alle fouten van één review, alle fouten van alle reviews in een bepaald project of alle fouten van een bepaald proces. Het is niet zinvol om alle fouten te analyseren. De vraag welke fouten worden geanalyseerd is afhankelijk van de volgende aspecten: • de gevolgschade als de fout niet wordt gevonden;


De verschillende reviewtypen.

30

verbeterd product

De volgende reviewtypen worden onderscheiden (op basis van IEEE 1028): • Collegiale review. De collegiale review is een informele review uitgevoerd door een of meer collega’s. • Walkthrough. Bij een walkthrough leidt de auteur een groep door een document of een ander product en licht de auteur de achterliggende gedachtes en keuzes toe. • Inhoudelijke review. De inhoudelijke review is een gestructureerde, inhoudelijke beoordeling van een product door een of meer reviewers met als doel te bepalen of het product bruikbaar is voor het doel waarvoor het is gemaakt.

• Inspectie. Een inspectie is een formele verificatie methode georganiseerd en begeleid door een getrainde moderator. Het doel van een inspectie is het vinden van fouten en het achterhalen van de oorzaak van fouten. • Managementreview. Een managementreview is gericht op het bepalen van de status van een project. Op basis van deze status wordt besloten over de voortgang van een project. Uit onderzoek blijkt dat bij een formeler reviewtype meer fouten worden gevonden (Jones, 1996). Bij een informele review van een ontwerp wordt 25 tot 40 procent van de fouten gevonden, bij een formele review van een ontwerp 45 tot 65 procent.

wens

werkelijkheid

requirements

acceptatietest

walkthrough

functioneel ontwerp

inspectie

technisch ontwerp

realisatie

inhoudelijke review

collegiale review

systeemtest & ketentest

integratietest

programmatest

Figuur 3. W-model

Het analyseren van de fouten gebeurt in een sessie waarbij de deelnemers onder leiding van een facilitator de oorzaak of oorzaken van de geselecteerde fouten achterhalen. Voor het analyseren zijn verschillende technieken beschikbaar, zoals het visgraatdiagram, de foutboomanalyse, de Paretoanalyse en indeling in de POCOT-categorieën (Proces, Opleiding/kennis, Communicatie, Organisatie en Technologie). Op basis van de oorzaak stellen de deelnemers verbetervoorstellen op. De vraag hierbij is wat er moet veranderen in de werkwijze van de organisatie om de fout te voorkomen of de fout eerder te vinden. Voor het opstellen van verbetervoorstellen kunnen heel goed brainstormtechnieken worden gebruikt. Uiteindelijk levert de causale analyse verbetervoorstellen op aan de hand waarvan de organisatie haar processen kan verbeteren. Hierbij geldt wel één waarschuwing: het implementeren van de verbetervoorstellen hoort niet bij de causale analyse. Als er echter niets met de verbetervoorstellen gebeurt, neemt de bereidheid om tijd te besteden aan het analyseren van fouten zienderogen af.

Tot slot Testen is in veel organisatie onomstreden maar wel vaak een inefficiënt proces. Veel van de gevonden fouten worden vroeg in een ontwikkeltraject gemaakt. Hoewel reviews nooit geheel in de plaats kunnen komen van het testen, kunnen door het professioneel uitvoeren van reviews onnodige reworkkosten en onnodige uitloop worden voorkomen. Het op professionele wijze uitvoeren van reviews op zichzelf levert al veel op, door de uitkomsten van de reviews in de vorm van de fouten optimaal te gebruiken neemt de toegevoegde waarde van reviews nog verder toe. Op die manier worden organisaties op lange termijn (nog) succesvoller. Er zijn voldoende bewijzen om (project) managers hiervan te overtuigen.

review

conceptproduct

project

verbeterd product

procesverbeteringen

Figuur 4. Reviews met foutpreventie

analyse bevindingen

foutpreventie


• het aantal gelijksoortige fouten; • de inspanning die het kost om de oorzaak van de fout weg te nemen; • de inspanning die het kost om een fout nu te herstellen.

31


t


Dit artikel is in hoge mate gebaseerd op het boek Reviews in de praktijk: testen aan de voorkant (Cannegieter e.a., 2008), het enige Nederlandstalige boek over reviews.

32

Literatuur Cannegieter, H.J.J. e.a. (2008). Reviews in de praktijk: testen aan de voorkant. Den Haag: Academic Service. Fagan, M.E. (1976). Design and Code Inspections to Reduce errors in Program Development. IBM Systems Journal 15(3). Gilb, T. & D. Graham (1993). Software Inspections. Addison Wesley. Grady, R.B. (1992). Practical metrics for project management and process improvement. Prentice Hall. Humphrey, W. (1989). Managing the software process. Addison Wesley. Jones, C. (1996). Software defect removal efficiëncy. Computer 29 nr. 4 (april). Jones, C. (2000). Software Assessments, benchmarks, and best practices. Addison Wesley. Larson, R. (1975). Testplan and Testcase inspection specification. IBM Report TR 21.586. Remus, H. (1978). Directions for the Applications of Structured Methodologies. IBM report TR 03.050. Rico, D. (2002). How to Estimate ROI for Inspections, PSPsm, TSPsm, SW-CMM®, ISO 9000, and CMMIsm. StickyMinds, september 2002. Standish Group (2006). The Chaos Report. Jan Jaap Cannegieter is adjunct-directeur, consultant en docent bij SYSQA B.V. E-mail: [email protected]. Mark van der Zwan is consultant en docent bij Improve Quality Services B.V. E-mail: [email protected].

»Door het professioneel uitvoeren van reviews kunnen onnodige reworkkosten en onnodige uitloop worden voorkomen

«

Voordelen van reviewen Reviews voorbereiden en uitvoeren kost tijd en geld. Medewerkers zijn er al gauw een aantal uur mee bezig en de tijd die eraan besteed is kan niet ergens anders aan besteed worden. Tegenover deze kosten moeten natuurlijk wel opbrengsten staan. Al jarenlang weten we dat er grote kwantitatieve voordelen te behalen zijn met reviews. Een kleine greep uit de literatuur: • 23 procent besparing op programmeren en 25 procent reductie van doorlooptijd (Fagan, 1976); • afname van het ICT-budget met 15 procent (Remus, 1978); • afname van de testinspanning met 80 tot 85 procent (Remus, 1978; Larson, 1975); • stijging van de productiviteit met 30 tot 100 procent (Gilb & Graham, 1993); • afname van de doorlooptijd met 10 tot 30 procent (Gilb E Graham, 1993); • afname van tests met factor 5 tot 10 (Gilb & Graham, 1993); • afname van de onderhoudskosten met factor 2/3 (Gilb & Graham, 1993); • return on investment (ROI) van 10 en afname van de time-to-market met 18 maanden bij Hewlett-Packard (Grady, 1992); • afname van de kosten om fouten te vinden met factor 10 en toename van de productiviteit van 14 procent bij AT&T (Humphrey, 1989); • ROI van 37 (Rico, 2002).

In de periode van 2001 tot heden heeft een van de auteurs bij diverse implementaties van reviews een ROI tussen de 5,9 en 7,7 gehaald. Bij één opdrachtgever is in een half jaar tijd 760.000 euro bespaard, bij een andere opdrachtgever in een half jaar 1,6 miljoen euro. Ook zijn er niet-kwantitatieve voordelen van reviews, zoals: • minder onverwachte uitloop; • betere documentatie; • betere communicatie tussen de disciplines; • initiatie van procesverbetering; • soepelere testuitvoering; • soepelere oplevering van systemen; • betere stuurinformatie; • hogere klanttevredenheid; • betere werksfeer door minder problemen in projecten.

input: fouten

selecteren fouten

analyseren fouten

opstellen verbetervoorstellen

output: verbetervoorstellen

Figuur 5. Causale analyse

Testen aan de voorkant

Recommend Documents