Hoewel organisaties het belang van testen om het resultaat van ict-projecten te controleren inmiddels algemeen onderkennen, is er nog weinig ervaring met het succesvol inrichten van testen binnen de Prince II-structuur. Het rrbt-testmanagementmodel is gebaseerd op dezelfde uitgangspunten als Prince II en strookt daardoor met de projectbesturing van deze aanpak.
| Rrbt Het rrbt-testmanagementmodel (risk & requirement based testing) beschrijft de activiteiten van de testmanager vanaf de start van een project tot en met het moment van implementatie van het informatiesysteem. Door rrbt als uitgangspunt te kiezen ontstaat een integraal geheel waarbij alle testmanagementactiviteiten gericht zijn op het beheersen van risico’s. Doordat dit model niet afhankelijk is van een test- of ontwikkelmethode biedt het een goed uitgangspunt voor elk testproject. Zie: Succesvol Testmanagement: een integrale aanpak (isbn 90-440-0554-5). |
Om te kunnen controleren of het gewenste resultaat inderdaad bereikt is, moet er getest worden, daarover is iedereen het inmiddels wel eens. Er zijn echter nog weinig organisaties die ervaring hebben met het succesvol inrichten van het testen binnen de Prince II-structuur. Het officiële handboek van het Britse Office of Government Commerce geeft ook geen enkele aanwijzing over het testen.
Uitgangspunten
Logica CMG heeft het rrbt-testmanagementmodel (risk & requirement based testing) ontwikkeld. Dit model is gebaseerd op dezelfde uitgangspunten als Prince II: productgerichtheid, een strikt besturingsmodel en een duidelijke zakelijke rechtvaardiging (business case). Het te realiseren eindproduct is het uitgangspunt bij het inrichten van het project. Daartoe onderscheidt de projectmanager ook deelproducten met meerdere niveaus van diepgang. Op het eerste gezicht lijkt dit strijdig met het organiseren van testen. Testen is een activiteit, hoe kun je dat dan zien als een product? Hoe zorg je ervoor dat de specifieke structuur van de testorganisatie strookt met de Prince II-projectbesturing?
In de zakelijke rechtvaardiging beschrijft de ‘project board’ welke toegevoegde waarde het te realiseren product voor de organisatie zal hebben. Op een zeker moment wil die projectraad weten of dit werkelijk gehaald wordt.
Met het rrbt-testmanagementmodel neemt de projectmanager het testen zodanig in de projectorganisatie op dat deze uitgangspunten volledig ondersteund worden. Doorlopend wordt op een objectieve manier vastgesteld of het opgeleverde product de beoogde toegevoegde waarde kan leveren.
Productgericht
Traditionele ict-projecten zijn activiteitgericht. Eerst wordt bijvoorbeeld de functionele en technische documentatie geschreven, dan volgen bouw van programma’s, en testen en ingebruikname van het systeem. Prince II-projecten daarentegen zijn productgericht. De projectmanager beschrijft wat het uiteindelijke product is, bijvoorbeeld een ordersysteem. Vervolgens geeft hij in de ‘product breakdown structuur’ grafisch de structuur van het product weer. Het ordersysteem bestaat uit een klanten- en een orderadministratie. De laatste is weer onderverdeeld in orderinvoer, orderbevestiging enzovoort. Het product wordt opgedeeld tot het laagste niveau dat nog zinvol is voor de projectbesturing. In de productgerichte aanpak kun je de activiteit testen niet zondermeer onderbrengen. Dit wordt opgelost door een specifiek testproduct toe te voegen aan de ‘product breakdown structuur’, bijvoorbeeld een ‘acceptatie getest order systeem’.
Voor elk product worden de karakteristieken in de ‘product description’ vastgelegd. Ook van de specifieke testproducten die zijn toegevoegd leg je dus vast waar het product uit bestaat en aan welke kwaliteitscriteria het moet voldoen.
Voor de producten op de laagste niveaus in de ‘product breakdown structuur’ is het niet effectief om extra testproducten te definiëren. Daarom wordt voor die producten in de kwaliteitskenmerken vastgelegd dat het product aantoonbaar aan bepaalde criteria voldoet. Dit wordt geverifieerd in testsoorten als unit- en systeemtest.
| Testmanagement Prince II en het rrbt-testmanagementmodel zijn ontstaan uit praktijkervaringen. Beide richten zich op het praktisch uitvoeren van projecten. Hierbij gaat het eindresultaat bereiken als leidraad boven richtlijnen en procedures volgen. Beide modellen bestaan uit diverse componenten waarmee een project flexibel valt in te richten. Afhankelijk van de omvang, complexiteit en behoeften in een project wordt per component besloten in welke mate het wordt toegepast. Ook alternatieve componenten zijn in te passen. Het rrbt-testmanagementmodel schrijft bijvoorbeeld een standaard bevindingenbeheerprocedure voor, maar organisaties kunnen ook een eigen procedure toepassen. Risicomanagement is een belangrijk component binnen Prince II. De rrbt-testmanagementaanpak richt het testproces in op basis van een productrisicoanalyse en de vereisten. Die analyse vormt de essentiële invoer voor de teststrategie. Hij stelt vast welke productrisico’s aan het product verbonden zijn (bijvoorbeeld: een responstijd van meer dan 2 seconden is voor de eindgebruikers niet werkbaar). De belangrijkste risico’s krijgen meer aandacht en worden als eerste getest. Prince II verdeelt een project in ‘stages’ (vooraf gedefinieerde fases). Initieel wordt een globale planning opgesteld. Aan het eind van fase wordt het plan voor de volgende gedetailleerd uitgewerkt. Ook het rrbt-testmanagementmodel maakt iteratief planningen, gebaseerd op de theorie van het evolutionair plannen. Hierbij worden leerervaringen gedurende het project gebruikt om zo realistisch mogelijke tijdplanningen te maken voor de resterende fases. |
Verantwoordelijk
In een Prince II-project is de projectraad eindverantwoordelijk. De projectmanager heeft de verantwoordelijkheid voor de dagelijkse gang van zaken. De projectmanager geeft voor elk product een ‘work package’ aan een teammanager. Die zal samen met zijn team dat product opleveren. In het Prince II-proces cs (controlling a stage) voert de projectmanager zijn besturende taken uit, terwijl mp (managing product delivery) de taak van de teammanager is.
Veel ict’ers worstelden met de vraag hoe de testverantwoordelijkheid in deze projectbesturing ondergebracht moest worden. De voor de hand liggende oplossing (testmanager is teammanager) past niet in alle gevallen. Een combinatie van twee soorten testmanagement biedt hiervoor de oplossing. In situatie één is er een specifiek testproduct, dus zijn alle werkzaamheden gericht op testen. Hier vervult een testmanager de rol van teammanager. Het gaat bijvoorbeeld om een acceptatietest. In situatie twee is er een algemeen product, op een lager niveau in de ‘product breakdown structuur’. Het testen is onderdeel van het werk aan dit product (bijvoorbeeld een unit-test tijdens de bouwfase). In dit geval zal een projectleider de rol van teammanager vervullen en valt het testen binnen zijn verantwoordelijkheid. De projectleider kan besluiten om binnen zijn team een testcoördinator aan te stellen. Die wordt in het Prince II-besturingsmodel echter niet herkend omdat hij vanuit de projectmanager gezien onderdeel is van een team.
Besluitvorming
De projectmanager volgt in het proces cs de dagelijkse gang van zaken bij het realiseren van de producten binnen een bepaalde fase (stage). Om deze controle effectief te kunnen uitvoeren, krijgt hij input van de testmanager in de vorm van voortgangrapportages (checkpoint reports). Naast de rapportage in tijd en geld geven deze ook inzicht in de kwaliteit van het product voor wat betreft afgedekte productrisico’s en vereisten. De testmanager geeft inzicht in de kwaliteit van het product en ook een indicatie hoeveel inspanning nog nodig is om een acceptabel eindproduct op te leveren. In het rrbt-testmanagementmodel zijn deze rapportages ingebed in de gehele testaanpak.
Binnen Prince II is het essentieel dat de projectraad na elke fase een weloverwogen ja/nee-beslissing (go/no go) neemt. Daardoor kan het project niet ongecontroleerd voortkabbelen. Op deze vooraf vastgestelde momenten beoordeelt de projectraad of het product nog steeds voldoet aan de doelstellingen zoals vastgelegd in de productspecificaties en de zakelijke rechtvaardiging. Om deze beslissing te kunnen nemen, heeft zij informatie nodig over in hoeverre de opgeleverde producten voldoen aan de vooraf vastgestelde kwaliteitscriteria. Daar komt het testen om de hoek. De testmanager rapporteert op een gestructureerde manier wat de resultaten van de test waren, welke openstaande bevindingen er nog zijn en van welke productrisico’s inmiddels is aangetoond dat ze niet zullen optreden.
Bij de start van het project heeft de projectraad een zakelijke rechtvaardiging opgesteld. Daarin beschrijft zij welke toegevoegde waarde het te realiseren product voor de organisatie zal hebben. Door toepassing van het rrbt-testmanagementmodel worden de testprocessen zo ingericht dat het testen relevante en gerichte managementinformatie oplevert. Hiermee wordt objectief vastgesteld of het opgeleverde product de beoogde toegevoegde waarde werkelijk kan leveren.
Soms blijkt uit de testresultaten dat de kosten die je moet maken om het gewenste kwaliteitsniveau te halen hoger zijn dan geraamd in de zakelijke rechtvaardiging. Door het gebruik van rrbt is dat al in een vroeg stadium bekend en kan de projectraad handelen volgens het spreekwoord ‘beter ten halve gekeerd dan ten hele gedwaald’.< BR>
Rik Marselis, Erik Brouwer, Test Research Centre van Logica CMG
