In een dagdeel direct toepasbare risico-inzichten voor gerichte QA
Een aantal jaar terug was ik actief op een toffe opdracht waar ik aan een voorstel voor generieke testafspraken. Omdat er expliciet gevraagd werd naar risk-based testing, wilde ik een risicoanalyse toevoegen – en die tegelijk zo laagdrempelig mogelijk maken om mee te starten. Dat klinkt eenvoudig, maar hoewel het begrip vaak genoemd wordt, zie ik het in de praktijk zelden écht toegepast. Dus vroeg ik me af: hoe pak ik dat aan?
Toevallig kwam er precies op dat moment een workshop over risicoanalyse voorbij tijdens het TestNet-event. Een mooie kans om inspiratie op te doen! Tijdens die sessie ontdekte ik dat de manier waarop ik mijn risico’s structureerde, hielp om gerichte vragen te stellen en zo een vollediger beeld van de risico’s te krijgen. De sleutel daarbij was: een mindmap.
Mindmap
Als start stel ik één vraag voor de business: Noem eens een risico. In het voorbeeld hieronder nemen we een muziekfestival.
A: Noem eens een risico
B: Nou het betalingssysteem lag er een keer uit
A: Ok nu ga ik een vraag stellen die snel irritant kan zijn, dus vergeef me dat even, we gaan ergens heen. Waarom is dat een probleem?
B: Geen drankverkoop
A: Ok, waarom is dat een probleem
B: Te weinig inkomsten
A: Ok.. Waarom is dat een probleem
B: in ergste geval faillissement
Deze informatie geven we vervolgens weer in een mindmap zoals hieronder.
Deze aanpak geeft de mogelijkheid om bij elke stap te vragen: “Wat kan dit nog meer veroorzaken?”
Bijvoorbeeld: zijn er nog andere factoren die kunnen leiden tot te lage barinkomsten?
Op die manier zorgt elk nieuw risico weer voor inspiratie om verder te denken en de lijst aan te vullen met andere mogelijke risico’s.
Blijven we even bij dit voorbeeld, dan kun je vervolgens de vraag stellen: “Welke IT-systemen spelen hierbij een rol?” Het antwoord zou er dan ongeveer zo uit kunnen zien (ingezoomd op het rechter deel van de mindmap):
Het doel hiervan is om een zo compleet mogelijk beeld te krijgen van alle risico’s in en rond de software waar het team zelf verantwoordelijk voor is.
Daarom is het belangrijk om dit samen te doen met zowel IT’ers als de business. Dat levert niet alleen een vollediger overzicht op, maar zorgt ook voor een gedeeld begrip van de risico’s.
Opzetten risico kwalificatie
Als definitie van risico horen we vaak de term “kans maal schade” voorbijkomen. Maar klopt dat eigenlijk wel voor ons, in de IT?
Stel: een man komt bij de dokter en krijgt te horen dat hij een operatie nodig heeft met een 2% kans op overlijden. Voor die man is dat een kans.
Het ziekenhuis daarentegen voert duizend van zulke operaties per jaar uit, wat betekent dat er gemiddeld twintig patiënten overlijden. Voor een productieomgeving als een ziekenhuis is het dus eigenlijk een kwestie van frequentie, niet kans.
Maar wat betekent “kans” dan voor ons, in de IT? Frequentie is lastig vooraf te bepalen. Daarom draait het voor ons meer om vertrouwen (in onszelf en in ons team) dat we de software veilig en stabiel naar productie brengen. En daarmee verandert de vraag: wat zijn de dingen die ons dat vertrouwen zouden moeten geven?
Vertrouwen:
- Developers hebben goed inzicht en ervaring met de code.
- Acceptabel technical debt in de code.
- Documentatie is voldoende inzichtelijk en up to date.
- Er is voldoende dekking met automatische tests.
- Het team is goed bekend met alle geraakte functies.
- Recente ervaringen met changes is dat ze helder beschreven zijn en het team een gedeeld begrip ervan heeft.
- Team is in staat om voldoende tests uit te voeren (denk aan dekking, maar ook aan soorten zoals GAT).
- Het aantal (ernstige) bevindingen tijdens eerdere ontwikkelingen was laag.
Hoe meer er van dit soort punten afgeweken wordt, hoe minder vertrouwen er is en dus hoe groter de kans. De inhoud van deze lijst kan in specifieke omgevingen uiteraard afwijken.
Wanneer we het over schade hebben, kijken we naar de directe gevolgen van een risico als het misgaat. Dat kan bijvoorbeeld financiële schade zijn, extra werk, frustratie bij collega’s of reputatieschade. Een belangrijk onderdeel daarvan zijn de vragen hoe snel een incident wordt ontdekt en hoe werkbaar de situatie op dat moment blijft. Twee belangrijke factoren in hoe groot de potentiële schade is.
Daarna komt het onderdeel gevolg: de bredere repercussies voor de bedrijfsvoering. Denk aan de noodzaak om extra personeel in te zetten, een verhoogde werkdruk (met mogelijk meer ziekteverzuim), verlies van inkomsten, mogelijke boetes of zelfs een verslechterde concurrentiepositie.
Dus samengevat als we het hebben over de onderstaande termen, bedoelen we:
Kans: relatieve inschatting dat iets fout kan gaan
Frequentie: objectieve meting hoe vaak productie incidenten voorkomen.
Vertrouwen: gestaafd gevoel van hoeverre we in control zijn
Schade: het directe resultaat wanneer het risico tot uiting komt
Gevolg: de repercussies voor de bedrijfsvoering die voortkomen uit de risico’s
Risico: vertrouwen beperkende factoren maal schade
Toewijzen risico’s
Nu de termen helder zijn, kunnen we beginnen met het definiëren van de risiconiveaus. Ieder team kan hier methoden en definities nemen die goed passen in hun context. Zelf werk ik graag met vijf niveaus. Voor het muziekfestival kan dat er bijvoorbeeld uitzien zoals op de afbeelding rechts:
Met deze methode in de hand kan het team vervolgens ieder eerder geïdentificeerd risico een score geven op vertrouwen beperkende factoren en schade. Daarna kun je de risico’s eenvoudig sorteren op hun risicoscore (vertrouwen beperkende factoren × schade).
Het is verstandig om deze volgorde samen met het team nog een keer door te lopen. Soms voelt een risico, ondanks de berekende score, hoger of juist lager aan. Dat zijn waardevolle signalen om mee te nemen in de uiteindelijke prioritering.
