Door: Gerben de la Rambelje
Auteur: Jurian van de Laar ● jurianvdlaar@xs4all.nl
Het lijkt al weer een tijd geleden dat ik door Willem van Strik gebeld werd met de vraag of ik tijdens een TestNet-avond over Product Risico Analyse een presentatie wilde geven. Chris Schotanus organiseerde een Product Risk Analysis Workshop (PRAW) zoals hij die bij CGI toepast. Bij Improve Quality Services hanteren we de Product Risk Management (PRISMA®) aanpak en daarin worden ook de cursisten in onze trainingen opgeleid. Eigenlijk heeft elke Test Methodiek en elke aanbieder wel een eigen manier en TestNet wil als onafhankelijke vereniging verschillende van die alternatieven laten zien.
Na afloop heb ik nog veel positieve reacties gekregen op deze avond, waaronder van Gerben de la Rambelje, met het idee om over dit onderwerp een stukje te schrijven voor de TestNet Nieuws Blog. Dat doe ik natuurlijk graag, al heeft het even geduurd voordat ik er echt eens voor ben gaan zitten om mijn ideeën over Risico Analyse op een rijtje te zetten.
Keuzes
Testers weten dat alles uitputtend testen in de praktijk onmogelijk is, dus dat je altijd keuzes moet maken. Ik denk dat een Product Risico Analyse, volgens welke methode dan ook, de meest toegepaste manier is om dat te doen. Maar is de methode om de risico’s te bepalen betrouwbaar genoeg? Is er voldoende draagvlak: zijn alle belangrijke stakeholders het eens over de ingeschatte risico’s? En ook belangrijk: hoe gebruiken we de informatie uit de risico analyse vervolgens in de testaanpak? En andersom: hoe dragen de testen vervolgens bij aan het afbouwen van risico en wordt het risicoplaatje daar dan ook regelmatig op aangepast? In een korte inventarisatie tijdens de TestNet avond bleek maar een enkeling op al deze vragen een antwoord te hebben èn dit allemaal ook echt in de praktijk toe te passen.
Risico wordt vaak gedefinieerd als het product van foutkans en consequentie. Die vermenigvuldiging is eigenlijk vreemd omdat het suggereert dat kans en impact elkaar zouden kunnen compenseren. In de PRISMA-methode worden deze twee componenten in twee dimensies, op aparte assen uitgezet. In deze tweedimensionale ruimte wordt de positie van elk risico item (dat een feature, functie, requirement of component kan zijn) bepaald door de impact van een fout in horizontale richting en door foutkans in verticale richting.
Wat maakt deze PRISMA-methode nu zo krachtig en waarom wordt deze – ook mijn eigen praktijk – vaak toegepast?
De assen: door kans en gevolg in verschillende richtingen uit te zetten in de zogenoemde risicomatrix kan de tester, afhankelijk van het doel van zijn testen, een keuze maken uit het vinden van zoveel mogelijk fouten (focus op verticale as in bijvoorbeeld in systeemtesten) of juist het vertrouwen in het product vergroten door schade zoveel mogelijk te beperken (focus op horizontale as in bijvoorbeeld acceptatietesten).
Matrix
Door de risico’s uit te zetten in een tweedimensionaal vlak (risicomatrix) en beide assen te splitsen in een ‘laag’ en een ‘hoog’ deel, ontstaan vier kwadranten. Daarmee worden de risico’s direct inzichtelijk gemaakt (managers begrijpen dit plaatje 😉 en is voor de tester is ook veel gemakkelijker uit te leggen waarom de risico-items in het kwadrant rechtsboven (hoge foutkans, hoge impact) de meeste testinspanning vergen en de hoogste prioriteit verdienen.
Factoren
Het bepalen van de positie van risico-items in de matrix is vaak lastig en kan tot veel discussies leiden. Het inschatten van risico’s is – per definitie – ‘gokken’. Als alle fouten en gevolgen bij voorbaat bekend zouden zijn, zouden risico’s feiten zijn en zouden we ook geen testen nodig hebben om de fouten te vinden 😉 Toch is het belangrijk om een zo hoog mogelijke betrouwbaarheid van de risico-inschatting te bereiken. Risicofactoren kunnen helpen om foutkans en invloed van fouten een onderbouwing te geven met productelementen die het risico enigszins concreet maken. De foutkans wordt bepaald door factoren als complexiteit en omvang van een risico-item, maar bijvoorbeeld ook de ervaring van de softwareontwikkelaar. Voor impact kunnen factoren als externe zichtbaarheid en (verwachte) mate van gebruik gehanteerd worden.
Stakeholders
In de PRISMA-methode spelen de belanghebbenden een bepalende rol. Voor het inschatten van foutkans en consequenties kunnen verschillende stakeholders worden uitgenodigd. De inschatting maken ze individueel, maar daarna komen ze bij elkaar om consensus te bereiken over hun inschattingen en dat is cruciaal. Door het ‘zo maar’ rekenkundig uitmiddelen van resultaten zouden extreme verschillen tegen elkaar wegvallen en daarmee zou mogelijk belangrijke informatie verloren gaan. Als de inschattingen van verschillende stakeholders – over hetzelfde item! – ver uiteen liggen, dan is juist de discussie interessant om de benodigde informatie boven te krijgen. Belangrijker nog: wanneer de stakeholders consensus hebben bereikt, dan is er ook draagvlak in het project en staat de tester vervolgens ook niet alleen in zijn verdediging van de testinspanning die nodig is voor de ‘hoog-risico’-items.
Gedifferentieerde testaanpak
Met de risicomatrix die het resultaat is van de analyse, kan voor het testen van de risico-items per kwadrant een andere aanpak worden gekozen. De mogelijkheden zijn legio. De meest grondige testtechniek voor het hoogste risico. De meest ervaren tester inzetten voor het hoogste risico. Informele technieken als Error Guessing voor laag risico, of juist als aanvulling op formele technieken in een hoog risico kwadrant.
Tool ondersteuning
Bij TASS Software Professionals, toen ik er nog werkzaam was nog Philips TASS, hebben we een applicatie ontwikkeld om de PRISMA-methode te ondersteunen. Dat vergemakkelijkt het genereren en verwerken van de invulformulieren (uitgevoerd als Excel-sheets) en ondersteunt de consensusmeeting met de stakeholders.
De praktijk is echter vaak weerbarstig. Stakeholders zijn niet altijd gemakkelijk beschikbaar of zijn soms niet bereid om veel tijd te investeren in de risicoanalyse. In mijn praktijk zie ik vaak dat er heel veel risico-items worden opgevoerd (meer dan 35 is eigenlijk al niet meer te hanteren) en bovendien veel risicofactoren ter onderbouwing van foutkans en impact. Voor de stakeholders wordt het invullen van de Excel-sheet een heel karwei. Bovendien vinden ze het vaak lastig moeilijk om duidelijk onderscheid te maken (‘alles is even belangrijk’), waardoor de risico-items in de resulterende matrix bij elkaar dreigen te ‘klonteren’, en dan ook nog eens in de rechter bovenhoek. Maar een nog belangrijkere reden waarom stakeholders in mijn praktijk moeite hebben om mee te doen is dat ze vaak zelf al lang een indruk hebben van de risico’s.
De hele methode lijkt in hun ogen een omslachtige manier om de bekende weg te bewandelen. Het invullen van uitgebreide Excel-sheets, een lange consensusmeeting, de moeizame weg om tot schattingen te komen die vaak maar heel beperkt te onderbouwen zijn, dit alles wordt vaak als een (te) zwaar proces beschouwd. In mijn huidige project hebben we daarom voor een meer pragmatische invulling gekozen. Zonder tools, met een eenvoudige invultabel voor de stakeholders. Maar toch, toevallig net nadat ik tijdens de TestNet-avond de resultaten had getoond, gaven de stakeholders toch de voorkeur aan eenvoudig ‘schuiven’ met de kruisjes in de matrix naar een positie die in hun ogen beter overeenkwam met hun ‘gevoel’ voor het risico.
In Agile-projecten past een wat eenvoudiger, minder procedurele maar wel intuïtieve manier meestal beter. In 2012 hebben we daarom RiskPoker® geïntroduceerd. Met een kleine aanpassing in het Planning Poker proces kan tijdens de Sprint Planning, tegelijk met het bepalen van Story Points, ook een risico-inschatting gemaakt worden. De Product Owner is verantwoordelijk voor een inschatting van impact (logischerwijs gekoppeld aan Business Value), het team maakt een inschatting van faalkans, op een vergelijkbare manier zoals dat met Planning Poker voor Story Points gebeurt. Niet in getallen (die een zekere nauwkeurigheid of wetenschappelijke onderbouwing zouden kunnen suggereren) maar in een vijftal kleuren. Ook in dit ‘lightweight’ proces wordt – nu door pokeren – consensus op faalkans gezocht. In de praktijk blijkt dit prima te werken en zien we dat alle belangrijke elementen als informatie uitwisseling, taken en stories scherp krijgen, inschatting van complexiteit en inschatting van risico bij elkaar te komen en elkaar te versterken.
Samenvatting
Er zijn veel verschillende manieren om een Product Risico Analyse uit te voeren. PRISMA® en RiskPoker® zijn twee van die manieren, ieder met hun kracht, maar ook een specifiek toepassingsgebied. Het is daarom belangrijk om bij het kiezen van een methode heel goed te kijken naar de context, de organisatie (cultuur) en de stakeholders.
Voor meer informatie over RiskPoker verwijs ik naar een artikel dat ik voor Agile Record heb geschreven (https://www.improveqs.nl/media/1161/agilerecord_10_laar.pdf). Voor ondersteuning bij het toepassen van een Product Risico Analyse in jouw eigen praktijk, zoals het PRISMA-boek (geschreven door Erik van Veenendaal), een set RiskPoker kaarten of het (gratis) PRISMA tool kun je mij een mailtje sturen (jurianvdlaar@xs4all.nl). Heel veel succes!