Testgedreven projectvoering

testen

t

Testgedreven projectvoering

Uitloop en budgetoverschrijding voorkomen

In veel it-projecten worden fouten in requirements en documentatie pas bij de testvoorbereiding ontdekt. Dit is duur omdat de fouten pas laat in het traject worden gevonden. De auteurs beschrijven hoe met behulp van testen fouten eerder kunnen worden gevonden om uitloop en budgetoverschrijding te voorkomen.

informatie / juli|augustus 2006

Jan Jaap Cannegieter en Cornell Heutink

32

1. In sommige publicaties worden ontwikkelaars aangeduid als constructief en testers als destructief (MacConnell, 2004). Ondanks het feit dat in de genoemde publicatie wordt gesteld dat destructief in de context van een it-project een goede, waardevolle eigenschap is die in het project aanwezig moet zijn om het project succesvol af te ronden, wordt deze formulering door de auteurs niet gebruikt vanwege de negatieve associatie met het woord ‘destructief’.

Bij diverse projecten komen onvolledigheden, onvolkomenheden en onduidelijkheden in requirements en functionele documentatie pas boven tafel bij de testvoorbereiding. Op zichzelf is het natuurlijk goed dat testers deze fouten vinden, maar het is ook duur omdat deze fouten laat in het traject gevonden worden. Vooral bij uitbesteding kunnen de gevolgen van laat gevonden fouten ernstige consequenties hebben. Wanneer de teststrategie vóór de ontwerpfase en de testvoorbereiding vóór de realisatie wordt gepositioneerd, worden deze fouten eerder gevonden. Op deze manier worden uitloop en budgetoverschrijding voorkomen, wat merkbaar bijdraagt aan het projectsucces, vooral bij uitbesteding.

Dure fouten In it-projecten zijn verschillende inhoudelijke rollen te onderkennen, in grote lijnen ontwerpers, ontwikkelaars en testers. Het blijkt dat testers duidelijk anders naar requirements en functionele documentatie kijken dan ontwerpers en ontwikkelaars. De laatste twee zijn gericht op het realiseren van oplossingen, activiteiten waarbij een beroep wordt gedaan op de creativiteit en inventiviteit. Testers zijn veel meer gericht op de juistheid en eenduidigheid.1 Bij onjuistheden of onduidelijkheden zoekt de ontwerper of ontwik-

kelaar naar een oplossing binnen de gegeven kaders, een tester zorgt ervoor dat eerst de onduidelijkheden en onjuistheden worden hersteld. Deze andere instelling van testers leidt ertoe dat ze fouten vinden, dat is ook hun werk. Helaas zijn fouten in requirements en functionele documentatie fouten die vroeg in het traject zijn gemaakt. Fouten die vroeg in een project worden gemaakt maar pas laat in het project worden gevonden, zijn relatief duur (zie figuur 1). Uit onderzoek blijkt dat 45 procent van de fouten die gemaakt worden tijdens it-projecten, afkomstig is uit de fasen requirements en ontwerp (NIST, 2002). De eraan gerelateerde herstelwerkzaamheden leiden over het algemeen tot ongeplande uitloop en bijbehorende budgetoverschrijding. Dit leidt nogal eens tot het verwijt in de richting van het testteam dat zij uitlopen. Onterecht, testen op zichzelf kost niet veel tijd, de fouten kosten veel tijd. Een fout vinden betekent namelijk controleren of het geen testfout is, bevinding aanmaken, herstellen en hertesten. Bij nieuwbouw- en onderhoudsprojecten die uitgevoerd worden door een interne it-afdeling is het in een laat stadium vinden van fouten lastig en duur, bij uitbesteding kan het desastreus zijn. Het principe ‘garbage-in is garbage-out’ gaat bij uitbesteding nog sterker op dan bij systeemont-

Samenvatting Bijna de helft van de fouten die worden gemaakt tijdens it-projecten, wordt gemaakt tijdens de requirements- en ontwerpfase. Veel van die fouten worden gevonden door testers, met als gevolg hoge herstelkosten. Dit leidt tot ongeplande uitloop en budgetoverschrijding. Wanneer de teststrategie vóór de ontwerpfase en de testvoorbereiding vóór de realisatie wordt gepositioneerd, worden deze fouten eerder gevonden.

1000

relatieve kosten

100

10

1

analyse

ontwerp

realisatie code

realisatie test

test & acceptatie

onderho d onderhoud

stadium herstel specificatiefouten

Figuur 1. Relatieve kosten om specificatiefouten te herstellen (Sassenburg, 2002)

wikkeling door een interne afdeling projecten. Medewerkers van een eigen systeemontwikkelafdeling hebben over het algemeen relatief veel businesskennis. Daarom valt het deze medewerkers eerder op dat iets niet goed is. Daarnaast is het vereiste detailniveau van de requirements en de functionele specificaties lager. Van een Indiase programmeur mag echter niet verwacht worden

dat hij of zij onze belastingregels of hypotheeksoorten kent. Daarnaast heeft de organisatie aan wie uitbesteed wordt geen belang bij het constateren en rapporteren van onjuistheden of onduidelijkheden. Dit leidt namelijk, hoe je het wendt of keert, altijd tot druk op budget of tijdslijnen en dus tot het openbreken van contracten. Bij uitbesteding vindt de acceptatietest pas na de oplevering plaats,

Het idee van het eerst opstellen van de testgevallen voordat met de bouw wordt begonnen, is de gedachte achter test driven development (tdd; Astels, 2003), ook wel aangeduid als extreme testing (Crispin & House, 2003). Tdd komt uit de agile systeemontwikkeling. Bij tdd moeten de bouwers eerst hun testgevallen voor de unittest maken; automatiseren voordat ze gaan programmeren. De gedachte hierachter is dat de bouwer door eerst testgevallen te maken beter inzicht krijgt in de materie en daardoor betere software maakt. Daarnaast blijkt de bouwer zijn unittest beter te doen bij het toepassen van tdd, waardoor de kwaliteit van de software beter wordt. Bij tdd is het uitgangspunt dat geautomatiseerde testscripts worden gemaakt. Het voordeel is dat de testuitvoering bijzonder weinig tijd kost, wat de doorlooptijd ten goede komt. Bij testgedreven projectuitvoering is dit ook getracht maar dit bleek niet mogelijk. Tools voor het geautomatiseerd functioneel testen zijn gebaseerd op applicaties met een userinterface. Geautomatiseerde testscripts bij unittests, zoals bij tdd, zijn geprogrammeerd. Met de opkomst van geautomatiseerde testtalen zoals TTCN-3 (Willcock e.a., 2005) kan het functioneel testen in de toekomst mogelijk ook worden geautomatiseerd zonder userinterface. Dit komt dan de doorlooptijd bij het toepassen van testgedreven projectvoering ten goede.


Testgedreven projectvoering versus test driven development

33

testen

t

teststrategie requirementsontwikkeling

testvoorbereiding

ontwerp

realisatie

testuitvoering

a traditionele samenhang

testvoorbereiding

teststrategie

waardoor het kwaad al lang geschied is. requirementsIn bestaande testmethoden zoals testontwerp realisatie ontwikkeling uitvoering TMap (Pol, Teunissen & Van Veenendaal, 1999), ISTQB (ISTQB, 2005; ook bekend als b samenhang h bij testgedreven d projectvoering j i ISEB) en TestFrame (Buwalda, Janssen & Pinkster, 2001) wordt een onderscheid gemaakt tussen Figuur 2: Samenhang systeemontwikkeling en testen het opstellen van de testplanning waarin onder andere de teststrategie wordt geformuleerd, de testvoorbereiding activiteiten op de genoemde momenten uitvoeren waarin de testgevallen en testscripts worden heeft een effect op de planning van het project; de opgesteld en de testuitvoering waarin de tests ontwerpfase begint niet voordat de teststrategie is worden uitgevoerd. Uitgangspunt bij al deze opgesteld en de realisatiefase begint ook niet methoden is dat de teststrategie wordt opgesteld voordat de testgevallen zijn gemaakt. Dit principe als de functionele specificaties worden gemaakt en wordt in de praktijk aangeduid als testgedreven de testvoorbereiding plaatsvindt tijdens de bouw. projectvoering, hetgeen zichtbaar is in figuur 2b. Als we de bestaande methoden dus toepassen zoals ze beschreven zijn, blijft het zo dat fouten die Voor- en nadelen vroeg in het traject gemaakt worden, voor een Het grootste voordeel van de testgedreven projectgroot gedeelte pas laat gevonden worden, met alle voering is dat de tester eerder fouten vindt, die gevolgen van dien. direct kunnen worden opgelost. Hierdoor neemt de kwaliteit van de specificaties aanzienlijk toe voordat het systeem wordt gerealiseerd. Het gevolg Testgedreven projectvoering hiervan is dat minder fouten later in het traject Het inzicht dat testers goed zijn in het vinden van worden gevonden, wat leidt tot minder ongeplande fouten in requirements of functionele documentauitloop. Uit de ervaring van SYSQA bij het toepastie heeft ertoe geleid dat bij menig project de sen van testgedreven projectvoering blijkt dat de teststrategie direct na het afronden van de requirerealisatie van het systeem in één keer goed gaat. ments wordt opgesteld en de testgevallen direct na Er zijn minder bevindingen, minder herstelwerkhet afronden van de functionele documentatie (zie zaamheden en minder testronden. De toegezegde figuur 2). Een eis die vaak aan requirements wordt gesteld, is dat eenduidig kan worden vastgesteld of aan de requirements is voldaan. Met andere woorden, dat de requirements zijn geformuleerd in de vorm van meetbare acceptatiecriteria. Als de requirements met een zodanige diepgang zijn uitgewerkt dat er een teststrategie op kan worden gebaseerd, zijn ze voldoende meetbaar. Wanneer de testers eerst hun testgevallen maken tijdslijnen worden gehaald en er is sprake van op basis van de functionele specificaties, worden weinig tot geen budgetoverschrijding. deze specificaties zodanig intensief gebruikt dat Tot nu toe is testgedreven projectvoering vooral onjuistheden of onduidelijkheden vrijwel zeker toegepast bij uitbesteding. Bij een organisatie waar aan het licht komen. Niet alleen de grote, voor de testgedreven projectvoering bij een drietal uitbehand liggende fouten worden gevonden, ook stedingstrajecten werd toegepast, zijn deze trajecdieperliggende fouten komen boven water. Beide ten merkbaar succesvoller verlopen. Als gevolg van


»Testgedreven projectvoering

34

zorgt ervoor dat de tester eerder fouten vindt«

het ontbreken van voldoende meetgegevens is dit niet kwantitatief te onderbouwen. Daarnaast ontstaat bij het toepassen van testgedreven projectvoering bij uitbesteding nog een interessante mogelijkheid tot kostenbesparing. Bij uitbesteding kunnen de testgevallen aan de uitbestedingspartner worden gegeven met de boodschap dat de software aan die testgevallen dient te voldoen. Hierdoor wordt de testuitvoering gedaan door de uitbestedingspartner. Overigens blijken deze uitbestedingspartners hier ook blij mee te zijn: zij besparen op hun testvoorbereidingskosten en worden na oplevering minder tot niet geconfronteerd met fouten die hersteld moeten worden. De uitbestedende organisatie hoeft er alleen op toe te zien dat de test juist en volledig wordt uitgevoerd. Dit kan door mee te kijken of steekproefsgewijs de test te herhalen. Het nadeel waardoor diverse organisaties nog huiverig zijn voor het toepassen van testgedreven projectvoering is dat de geplande doorlooptijd van het project toeneemt. Als pas met het ontwerpen mag worden begonnen als de teststrategie is opgesteld en pas met de realisatie wordt begonnen nadat de testgevallen zijn opgesteld, heeft dit een merkbaar effect op de planning. Vanuit de wens projecten in een zo kort mogelijke tijd te realiseren is het niet eenvoudig organisaties te overtuigen dat testgedreven projectvoering juist tijd oplevert doordat ongeplande uitloop wordt voorkomen. Hier doet zich het dilemma voor dat het opstellen van de teststrategie en het opstellen van de testgevallen wel gepland wordt en uitloop niet. Alleen organisaties waar onlangs een belangrijk project, bijvoorbeeld een uitbesteding, is gestrand of met veel uitloop en budgetoverschrijding is afgerond, staan open voor testgedreven projectvoering. Deze organisaties ervaren testgedreven projectvoering als het zoet na het zuur.

Praktische invulling Hoe kan testgedreven projectvoering het beste praktisch worden ingericht? Het lijkt voor de hand te liggen om een testmanager gedurende het hele project mee te laten lopen en bij de testvoorbereiding en de testuitvoering testers in te schakelen. Waar echter voor gewaakt moet worden, is dat de testmanager voordat de requirements opgesteld zijn bij het project wordt betrokken. De requirements dienen van een zodanige kwaliteit te zijn dat ze ‘zelfverklarend’ zijn; zonder dat je aanwezig bent geweest bij vooronderzoeken, impactanalyses en workshops dienen ze helder en eenduidig te zijn. Dit kan alleen beoordeeld worden door iemand die niet bij deze vooronderzoeken, impactanalyses en workshops is geweest. De testmanager dient dus, als hij degene is die de teststrategie opstelt, pas erbij betrokken te worden als de requirements klaar zijn. De testmanager kan wel als een soort kwaliteitsmanager voor het opstellen van de requirements eisen formuleren waar de requirements aan moeten voldoen. De testers dienen ook niet te vroeg betrokken te worden bij het opstellen van de functionele documentatie en derhalve tegen het einde van deze fase in te stromen. Pas dan kunnen de testers zich een onbevooroordeeld beeld van de specificaties vormen. Bij testgedreven projectvoering is te veel kennis een beperking. Bij het conventioneel gestructureerd testen is een van de eisen aan testscripts dat deze herbruikbaar zijn, iemand anders dan degene die het testscripts heeft opgesteld, moet het kunnen uitvoeren. De reden hiervoor is dat bij nieuwe releases andere gebruikers of testers gebruik moeten kunnen maken van de oude testscripts. In de praktijk wordt vaak in beperkte mate aan deze eis voldaan. Het persoonsonafhankelijk opstellen van testscripts kost meer tijd en in eerste instantie is dit

Het inzicht dat het eerder vinden van fouten uitloop en budgetoverschrijding voorkomt, is niet nieuw. Er zijn inmiddels ook methoden voor het definiëren en borgen van de kwaliteit tijdens de projectuitvoering (Cannegieter, 2001). Een belangrijk onderdeel van deze methoden is het uitvoeren van tussentijdse reviews zoals collegiale reviews, structured walkthroughs en inspecties. Bij dergelijke activiteiten wordt de kwaliteit van tussenproducten beoordeeld en worden gevonden fouten zo dicht mogelijk bij de bron hersteld. Hoewel de voordelen van deze methoden onomstreden zijn (Gilb & Graham, 1993; Rico, 2002), zijn ze niet waterdicht. Een serieus risico van deze kwaliteitsreviews is dat te veel fouten niet worden gevonden doordat de reviewers de producten met onvoldoende diepgang reviewen. Door tijdsdruk en onvoldoende aandacht voor de reviews worden de tussenproducten globaal doorgelezen en worden alleen de fouten die eenvoudig te vinden zijn gevonden. De tester vindt de minder eenvoudig te vinden fouten echter wel omdat hij of zij diep de documentatie in moet en er actief mee aan de slag gaat.


Testgedreven projectvoering en reviews

35

testen

t

niet echt noodzakelijk omdat de eerste test vaak door een en dezelfde tester wordt voorbereid en uitgevoerd. De nadelen van de beperkte herbruikbaarheid worden dan nog niet gevoeld. Bij testgedreven projectvoering is de herbruikbaarheid van testscripts echter essentieel. Per definitie zit er tussen testvoorbereiding en testuitvoering de nodige tijd, als deze activiteiten al door hetzelfde team worden gedaan. Het is dus heel wel denkbaar dat de test helemaal niet wordt uitgevoerd door degene die hem heeft opgesteld. Daarom dient bij testgedreven projectvoering nog sterker op herbruikbaarheid van testscripts gestuurd te worden.

Conclusie


Bijna de helft van de fouten die gemaakt worden tijdens it-projecten, wordt gemaakt tijdens de requirements- en ontwerpfase (NIST, 2002). Veel van die fouten worden gevonden door testers, met als gevolg hoge herstelkosten. Dit leidt weer tot ongeplande uitloop en budgetoverschrijding. Het wordt tijd dat we de vaardigheid van testers om fouten te vinden ten bate van het project gaan gebruiken door ze de kwaliteit van tussenproducten te laten beoordelen voordat deze producten verder worden verwerkt. Op die manier worden testers meer de borgers van kwaliteit dan de brengers van slecht nieuws.

36

Literatuur Astels, D. (2003). Test-driven development, a practical guide. Pearson Education. Buwalda, H., D. Janssen & I. Pinkster (2001). TestFrame. Sdu Uitgevers. Cannegieter, J.J. (2001). Kwaliteitszorg in ICT-projecten. Sdu Uitgevers. Crispin, L. & T. House (2003). Testing extreme programming. Pearson Education. Gilb, T. & D. Graham (1993). Software Inspections. ISTQB (International Software Testing Qualifications Board) (2005). Certified Tester Foundation Level Syllabus (ook bekend als ISEB Foundation). Version 2005. MacConnell, S. (2004). Code complete. Microsoft Press. NIST (2002). The Economic Impacts of Inadequate Infrastructure for Software Testing. Pol, M., R. Teunissen & E. van Veenendaal (1999). Testen volgens TMap. Tutein Nolthenius. Rico, D.F. (2002). How to estimate ROI for Inspections, PSP, TSP, SW-SMM, ISO 9000 and CMMI. Spider Koerier, september. Sassenburg, J.A. (2002). Software Engineering van ambacht naar professie of het huis in de bergen. Tutein Nolthenius. Willcock, C. e.a. (2005). An Introduction to TTCN-3. Wiley.

Jan Jaap Cannegieter is adjunct-directeur van SYSQA, een onafhankelijke organisatie gespecialiseerd in kwaliteitsmanagement en testen en (mede)auteur van de boeken Kwaliteitszorg in ICT-projecten, Software process improvement en De kleine CMM. E-mail: [email protected]. Cornell Heutink is fieldmanager van SYSQA. E-mail: [email protected].

Testgedreven projectvoering

Recommend Documents