Product Risk Analysis (PRA) - hoe kies je wat je test?

Wat is een Product Risk Analysis?

Een Product Risk Analysis, meestal afgekort tot PRA, helpt je bepalen waar een fout de grootste gevolgen kan hebben. Die onderdelen krijgen meer aandacht. Bij een lager risico kan een lichtere testaanpak voldoende zijn. Binnen het huidige TMAP wordt hiervoor de term Quality Risk Analysis gebruikt. Daarmee wordt benadrukt dat je kijkt naar kwaliteitsrisico’s die kunnen voorkomen dat een systeem de verwachte waarde levert.

Product Risk Analysis is de oudere term, maar wordt in de praktijk nog veel gebruikt. Zie je PRA of QRA voorbijkomen? Dan gaat het in de basis om dezelfde vraag: Waar kan het serieus misgaan en hoeveel zekerheid hebben we daar nodig?

Waarom kun je niet alles testen?

Omdat je geen onbeperkte tijd, mensen en budget hebt. En omdat niet iedere fout even ernstig is.

Een typefout op een informatiepagina is vervelend. Een klant die twee keer betaalt, is van een andere orde. Toch staan beide punten zonder risicoanalyse gewoon als twee regels op dezelfde testlijst.

Dat is precies waar het mis kan gaan. Teams besteden veel tijd aan onderdelen die makkelijk te testen zijn, terwijl de lastige en bedrijfskritische delen onder tijdsdruk blijven liggen.

Een PRA dwingt je om te kiezen. Niet op onderbuikgevoel, maar op basis van risico.

Hoe bepaal je een productrisico?

De simpele versie is: 

Productrisico = kans op falen × schade

De kans op falen zegt iets over hoe waarschijnlijk het is dat een onderdeel in de praktijk niet goed werkt. De schade beschrijft wat er gebeurt als dat inderdaad misgaat.

Neem een webshop. Een verkeerd uitgelijnd productplaatje verdient aandacht, maar zal de winkel niet direct stilleggen. Een fout in het betaalproces kan zorgen voor misgelopen omzet, dubbele afschrijvingen en een servicedesk die ineens een heel vervelende maandag heeft. Het betaalproces krijgt daarom een hoger risiconiveau. Niet omdat het gegarandeerd misgaat, maar omdat je daar minder graag een gokje mee waagt.

Wat vergroot de kans op falen?

Nieuwe technologie, ingewikkelde logica en veel afhankelijkheden maken fouten waarschijnlijker. Dat geldt ook voor onderdelen die in korte tijd vaak zijn aangepast.

Maar techniek is niet het hele verhaal. Ook de gebruiksfrequentie telt mee.

Een fout in een beheerscherm dat eens per jaar wordt geopend, komt waarschijnlijk minder snel aan het licht dan een fout in een knop waar duizenden mensen dagelijks op klikken. Het defect kan in beide gevallen bestaan. Alleen de kans dat gebruikers er werkelijk tegenaan lopen, verschilt behoorlijk.

Kijk daarom onder meer naar:

• de complexiteit van het onderdeel;
• nieuwe of onbekende technologie;
• recente wijzigingen;
• koppelingen met andere systemen;
• de ervaring van het team;
• hoe vaak de functie wordt gebruikt.

Je hoeft daar geen hogere wiskunde van te maken. Het doel is een eerlijk gesprek over waar het waarschijnlijk fout kan gaan.

Wat betekent ‘schade’ in een risicoanalyse?

Schade gaat niet alleen over geld. Een fout kan ook leiden tot reputatieschade, privacyschendingen, uitval van een bedrijfsproces of klanten die hun vertrouwen verliezen. Soms betekent schade vooral dat collega’s dagenlang handmatig gegevens moeten herstellen. Ook niet bepaald gratis.

Wat ernstig is, verschilt per organisatie. Een rapportage die een uur niet beschikbaar is, kan vervelend zijn. Een medisch systeem dat een uur uitvalt, is een heel ander verhaal. Daarom werkt een standaardlijst maar tot op zekere hoogte. Je moet weten hoe het systeem in de echte wereld wordt gebruikt en wie er last van heeft als het misgaat.

Een Product Risk Analysis doe je niet alleen

Je kunt de tester vragen om de risico’s te bepalen. Dat gebeurt ook regelmatig. Maar die tester weet niet automatisch wat een uur uitval kost, welke klantprocessen heilig zijn of welke technische koppeling met plakband overeind wordt gehouden.

Daar heb je meerdere mensen voor nodig.

De product owner kent de bedrijfsdoelen. De developer ziet technische complexiteit. De tester denkt na over foutkansen en testdekking. Operations weet wat er in productie gebeurt. Gebruikers en stakeholders kunnen vertellen wat een fout in de praktijk betekent.

Leg je die kennis bij elkaar, dan ontstaat een veel beter beeld dan wanneer iedereen afzonderlijk een risicolijstje maakt.

En ja, daar kan discussie uit ontstaan. Dat is niet erg. Die discussie is vaak precies de reden waarom je de analyse doet.

Prioriteit is niet hetzelfde als risico

Een user story met hoge prioriteit heeft niet automatisch een hoog productrisico.

Prioriteit zegt meestal iets over bedrijfswaarde of planning: wanneer willen we dit hebben? Risico stelt een andere vraag: wat gebeurt er als dit niet goed werkt?

Een functie kan belangrijk zijn voor de business en technisch toch vrij eenvoudig zijn. Andersom kan een weinig gebruikte beheerfunctie grote schade veroorzaken als iemand er per ongeluk alle klantgegevens mee wist.

Kort gezegd:

Prioriteit bepaalt wanneer je iets bouwt. Risico bepaalt hoeveel zekerheid je nodig hebt.

Die twee kunnen hetzelfde beeld geven, maar dat hoeft dus niet.

Hoe voer je een Product Risk Analysis uit?

Er bestaat geen verplichte PRA-ceremonie met een heilig Excel-bestand. Je kunt een workshop organiseren, interviews houden of Risk Poker gebruiken. Kies vooral een vorm waarmee mensen daadwerkelijk met elkaar in gesprek gaan.

Een praktische aanpak bestaat uit vijf stappen.

1. Bepaal wat je beoordeelt

Kies bijvoorbeeld bedrijfsprocessen, user stories, systeemonderdelen of kwaliteitskenmerken. “We analyseren het hele platform” klinkt ambitieus, maar levert meestal een middag vol algemeenheden op.

2. Zet de juiste mensen bij elkaar

Zorg dat zowel de business als IT vertegenwoordigd is. Je hebt mensen nodig die de impact kunnen inschatten én mensen die iets begrijpen van de technische foutkans.

3. Beschrijf wat er kan misgaan

“Het betaalproces is risicovol” is te vaag. “De klant betaalt, maar de bestelling wordt niet geregistreerd” is bruikbaar. Nu weet iedereen over welk probleem het gaat.

4. Beoordeel kans en schade

Gebruik cijfers of gewoon laag, midden en hoog. Zolang iedereen maar ongeveer hetzelfde bedoelt met die scores.

De uitkomst hoeft niet tot drie cijfers achter de komma te kloppen. Zo’n risicoscore is geen natuurkundige constante. Het gesprek erachter is belangrijker.

5. Kies passende kwaliteitsmaatregelen

Bepaal wat nodig is om het risico te verkleinen of zichtbaar te maken. Dat kan een review, proof of concept, geautomatiseerde test, specifieke testontwerptechniek of extra monitoring zijn.

Pas op dit punt wordt de risicoanalyse echt nuttig.

Van productrisico naar teststrategie

Een hoog risico betekent niet automatisch: meer testgevallen schrijven. Soms zit het probleem in een onduidelijke requirement. Dan kun je beter eerst samen om tafel dan achteraf twintig varianten testen. Bij een onbekende technische oplossing kan een proof of concept meer zekerheid geven. Voor een kritisch proces kan juist een combinatie van testautomatisering, exploratief testen en monitoring nodig zijn.

Je gebruikt de risicoanalyse dus om je complete kwaliteitsaanpak te bepalen. Wat testen we? Hoe diep testen we? En welke maatregelen kunnen fouten eerder voorkomen? Leg ook vast welk risico je met welke maatregel afdekt. Anders eindig je met een mooie gekleurde risicomatrix waarvan na twee sprints niemand meer weet wat ermee moest gebeuren.

Wanneer werk je de risicoanalyse bij?

Een PRA is geen document dat je één keer maakt en daarna plechtig archiveert. Nieuwe koppelingen, aangepaste wetgeving en onverwacht gebruikersgedrag kunnen het risicobeeld veranderen. Hetzelfde geldt voor testresultaten en productie-incidenten.

Kijk daarom opnieuw naar de risico’s wanneer de scope, techniek of gebruikssituatie verandert. Dat hoeft geen nieuwe workshop van een halve dag te worden. Soms zijn tien minuten tijdens een refinement al genoeg.

Risicogebaseerd testen met TMAP

Een Product Risk Analysis helpt je om beperkte testtijd bewust te verdelen. Niet alles krijgt dezelfde aandacht, omdat niet iedere fout dezelfde gevolgen heeft. In de e-learning TMAP: Quality for Cross-Functional Teams leer je hoe je kwaliteitsrisico’s samen herkent en vertaalt naar een passende teststrategie. Je ontdekt hoe je kwaliteit vanaf het begin meeneemt, in plaats van pas vlak voor de release te hopen dat alles goedkomt. Je kunt nu eenmaal niet alles testen. Maar je kunt wel zorgen dat je het belangrijkste goed test.