Is de Productrisicoanalyse de spreekwoordelijke Vogel Feniks?

Redactie: Gerben de la Rambelje
Auteur: Chris Schotanus ● chris.schotanus@cgi.com ● @CSchotanus

De afgelopen periode heb ik een aantal presentaties en workshops gegeven waarbij het ging over productrisicoanalyses en het nut daarvan bij testen van systemen. Eén van die workshops werd gehouden bij de thema-avond Risk-based teststrategie van TestNet 9 oktober jongstleden. Ik was bijzonder aangenaam verrast door het grote aantal testcollega’s dat deelnam aan die avond. Dat is voor mij een indicatie dat de PRA wel degelijk leeft!
Toch zien we dat de belangstelling voor de productrisicoanalyse afneemt, hoe onterecht dat ook is. Een reden die daarvoor wel genoemd worden is ‘dat de uitkomsten van de productrisicoanalyse toch verder niet worden gebruikt’. Ik zal dat hieronder pareren en een andere toepassing voor de productrisicoanalyse introduceren. Daarvoor breng ik de productrisicoanalyse naar een niveau hoger: van projectniveau naar domeinniveau. Maar eerst even kort de kennis opfrissen.
De productrisicoanalyse
In de moderne test(management)methoden worden productrisico’s gebruikt voor het vaststellen van de prioriteiten bij het testen. Als alles goed gaat, rapporteren de testers ook aan de hand van deze risico’s, zodat de go/no-go beslissing eenvoudiger te nemen is. Dit betekent dat elk project zal starten met een productrisicoanalyse in samenwerking met de stakeholders. We hebben het dan over Risk Based Testing of Risk & Requirement Based Testing, twee methoden die op details enigszins van elkaar verschillen.
Risk Based Testing en Risk & Requirement Based Testing
Bij Risk Based Testing of RBT wordt gekeken naar de risico’s die optreden wanneer een requirement of een daarvan afgeleide functie van een systeem faalt. Door aan het requirement toe te kennen hoe groot dat risico is, krijgt dit requirement zelf een prioriteit. Neem als voorbeeld een auto. Als die remmen niet naar behoren werken, is dat een hoog risico. Als de stadslichten het niet doen, is dat een laag risico.
Bij Risk & Requirement Based Testing of RRBT wordt iets breder naar risico’s gekeken: de risico’s worden door de stakeholders gedefinieerd zonder direct naar de requirements te kijken. Met andere woorden, de stakeholders denken wel aan het te ontwikkelen systeem, maar kennen de requirements nog niet in detail. Tijdens of na deze risicoanalyse worden, liefst door andere personen, de requirements opgesteld. Het resultaat van deze twee activiteiten is dus dat er twee lijsten zijn: één met risico’s en bijbehorende prioriteiten en één met requirements.

En daar zit het verschil tussen deze twee methoden. Bij RRBT zal door het vergelijken van beide lijsten worden gecontroleerd of zij compleet zijn: is er voor elk risico minimaal één requirement gedefinieerd en bestaat er voor elk requirement wel een risico. Bij een verschil zal onderzocht worden, waar dat verschil in zit en zal in overleg met de stakeholders een beslissing worden genomen. Dit wordt risk & requirements matching genoemd en is in feite de eerste daadwerkelijke testactiviteit.
Net als bij RBT krijgen ook bij RRBT de requirements uiteindelijk een prioriteit op basis van de risico’s.
Het nut van de productrisicoanalyse
Het nut van risico’s en daarmee aan de requirements toegekende prioriteiten is groot wanneer we in bijna alle fasen van het testproject de prioriteiten meenemen.
Teststrategie
In de teststrategie zal de testmanager vastleggen hoe het te testen systeem getest zal worden. Daarbij zullen de productrisico’s een belangrijke rol spelen. Immers hoog-risicorequirements vragen om een zwaardere testtechniek dan requirements met een lager risico. Ook zullen in de teststrategie de acceptatiecriteria worden vastgelegd. Deze worden dan uitgedrukt in mate van testen per risicocategorie.
Begroting/planning
Als het budget te klein is om alles te testen (wat meestal het geval is) kan de testmanager in overleg met de stakeholders bepalen welke belangrijke (risicovolle) delen zeker getest moeten worden en welke eventueel mogen afvallen. Tijdens het testproject worden de requirements met een hoog risico met voorrang getest.
Voortgangsbewaking
Tijdens de voortgangsbewaking zal de testmanager bewaken of de geplande kwaliteit is bereikt en of dat binnen het beschikbare budget is gebeurd. Voor het vaststellen van de kwaliteit wordt primair gekeken of, en in hoeverre, de productrisico’s zijn afgedekt door de kwaliteit van het te testen systeem.
Bevindingenbeheer
Bij elke bevinding wordt door de tester vastgelegd welk productrisico wordt geraakt. Aan de hand van deze gegevens wordt in het bevindingenoverleg bepaald of een bevinding wordt opgelost binnen de huidige release of dat het herstel wordt verschoven naar een volgende.
Rapportage en advies
Bij de testsoort- en testeindrapportage zal de testmanager rapporteren aan de stakeholders wat de uiteindelijke status van het testproject is en of het te testen systeem voldoet aan de acceptatiecriteria zoals deze in de teststrategie zijn vastgelegd.
Van project naar domein, van PRA naar DRA
De productrisicoanalyse vraagt een grote inspanning van zowel de testmanager als van de stakeholders. Hoewel de analysesessies waardevolle input opleveren voor het testproces, zijn ze niet altijd even efficiënt. Vaak zien we dat, wanneer voor meerdere projecten een productrisicoanalyse moet worden uitgevoerd, de stakeholders telkens dezelfde risico’s noemen met  slechts kleine verschillenop detailpunten. Dat is een gevolg van het feit dat de risico’s, los van de systemen, herkenbaar zijn binnen het business domein waar de systemen worden ingezet.
Als we dat nu eens verder beschouwen, kunnen we concluderen dat het analyseren van productrisico’s op het niveau van het domein helemaal zo gek nog niet is. Een productrisicoanalyse op dat niveau leidt tot een lijst met productrisico’s die kan worden gebruikt bij elk project dat binnen het domein wordt opgestart. De testmanager kan dan de beschikbare vooraf gedefinieerde lijst als leidraad gebruiken bij het vaststellen van de productrisico’s die gelden binnen het project. De testmanager kan in samenwerking met de stakeholders de risico’s die gelden voor het systeem aanscherpen: sommige gelden binnen het project misschien niet of in mindere mate, andere juist weer wel. Dit maakt dat het uitvoeren van een productrisicoanalyse per project een veel minder zwaar proces wordt.
Productrisicoanalyse en agile systeemontwikkeling
Wanneer we een risicolijst op domeinniveau ter beschikking hebben en het uitvoeren van een productrisicoanalyse minder ingrijpend is, zullen de productrisico’s ook bij agile ontwikkeling een belangrijkere rol kunnen spelen; we kunnen de risico’s immers ook koppelen aan user stories. En omdat we de risico’s al vóór het ontwikkelen helder hebben, kan dat eigenlijk continu. Elke keer wanneer we in de refinement user stories verder uitwerken kunnen we de risico’s laten meewegen. Zo zal bij de planning poker sessie het productrisico invloed hebben op de story points die aan een story worden toegekend en dus op de inspanning die nodig is voor het ontwikkelen en testen van de software die op basis van een user story wordt ontwikkeld. Zo wordt, juist omdat het uitvoeren van de productrisicoanalyse minder plaatsvindt bij elk systeemontwikkelingsproject, de toepasbaarheid in agile systeemontwikkeling groter.
Van RRBT naar RRBD: Risk & Requirement Based Development
Een risicoanalyse op niveau van business domein heeft dus veel voordelen boven een productrisicoanalyse per project: er wordt maar één keer een echte productrisicoanalyse uitgevoerd en de resultaten zijn voor elk project bruikbaar als input voor het vaststellen van testinspanning en sprintplanning. Maar waarom gaan we niet een stap verder: waarom gebruiken we de lijst met domeinrisico’s niet als leidraad voor wat wordt ontwikkeld en wat niet? Wanneer requirements een wenselijkheid hebben (van must have tot en met would have) en risico’s een prioriteit (van must test tot en met won’t test) kunnen we van een combinatie van die twee gebruikmaken.

Als we de risico’s en wenselijkheid tegen elkaar afzetten, krijgen requirements met een hoge wenselijkheid (must have) die gerelateerd zijn aan een hoog risico (must test) een hoge bouwprioriteit en zullen dus zeker worden geïmplementeerd en zwaar worden getest. Requirements met een lage wenselijkheid (would have) kunnen toch gerelateerd zijn aan een hoog risico. De implementatie van die requirements moet dus relatief zwaar worden getest. Je kunt je dan afvragen of het zinnig is om dat requirement daadwerkelijk te implementeren, immers het hoge risico vraagt om extra aandacht tijdens ontwikkeling en een zware testinspanning. De vraag is of die extra inzet opweegt tegen de behoefte aan de functionaliteit. Door bij die beslissing de productrisico’s zwaar te laten meewegen, komen we uit bij Risk & Requirement Based Development of RRBD.
Conclusie
De productrisicoanalyse of PRA en de lijst met productrisico’s die wordt geproduceerd tijdens dat proces is van essentieel belang voor een ​​testproject: het stelt de stakeholders in staat om acceptatiecriteria te definiëren en het ondersteunt de testmanager bij het definiëren van de scope en planning van het project. Als de resultaten van de PRA optimaal worden gebruikt gedurende het gehele testproces, wegen de kosten voor het uitvoeren van een PRA zeker op tegen de baten die bestaan uit meer inzicht in kwaliteit en beperking van de tijd die nodig is voor testen
De kosten kunnen we verder omlaag brengen wanneer we een PRA uitvoeren op niveau van het businessdomein en de resultaten gebruiken als leidraad binnen de projecten. Door het definiëren van de productrisico’s voor een businessdomein zal de tijd die moet worden besteed aan het uitvoeren van een productrisicoanalyse per project binnen dat domein afnemen en zal de efficiëntie van het testproces verbeteren.
Die domeinrisicoanalyse of DRA heeft nog meer voordelen. Doordat de productrisico’s al bekend zijn vóór een project wordt gestart, kan aan de hand van de risico’s in combinatie met de wenselijkheid om een requirement te implementeren worden beslist of de inspanning voor het implementeren en testen van dat requirement opwegen tegen het nut ervan. Zo worden risicobeheersingstechnieken uit de testwereld vertaald naar het gehele ontwikkeltraject, van RRBT naar RRBD en wordt de productrisicoanalyse een nieuw leven ingeblazen.