De term 'Risico'

Auteur: Bas Kruip

Ooit nagedacht over de risico’s die je loopt als je op vakantie gaat? Of de risico’s bij de aanschaf van een huis of auto? De risico’s bij het wisselen van baan? Als ik naar mijn eigen lichaam luister, en iemand begint over risico’s, dan stroomt het enthousiasme om te leven automatisch weg, om in een soort van vegetatieve serene toestand terecht te komen. De slogan “ik wacht wel tot dit alles voorbij is” dekt die emotionele lading vrij aardig. Natuurlijk: het concept ‘risico’ is belangrijk als het er bijvoorbeeld om gaat de beperkte tijd die we hebben om software te testen slim te gebruiken.

Maar de term 'risico’ zuigt.

In de hierboven beschreven beleving ben ik echt niet de enige: ik heb genoeg trainingen gegeven om te zien dat als ‘risicoanalyse’ als module langskomt, de motivatie zichtbaar daalt. En ik ben niet de enige: ook collega’s van me geven aan dat als er aan deelnemers wordt gevraagd risico’s te definiëren dit regelmatig leidt tot groepslethargie. De term 'risico’ lijkt ver van onze emotionele beleving rondom urgentie en belang af te staan.  
Daarnaast is de term ‘risico’ met regelmaat een onbegrepen begrip. Laat ik dit demonstreren aan de hand van de vaak gehoorde uitspraak: “Wat is het risico als we bug ‘zus en zo’ in productie nemen?” Deze uitspraak is ongeldig. Een risico is gelijk aan ‘kans x schade’. Het risico als we een bug naar productie brengen is dus altijd één, want de kans is immers één. Informatiever taalgebruik zou zijn: “Wat is de schade als we de bug in productie nemen?”

 

En we doen eigenlijk nauwelijks iets aan risicoanalyse.

In tegenstelling tot volwassen risicomanagement (waarin met drie cijfers achter de komma met allerlei denkbare variabelen wordt berekend wat de kans is dat er bijvoorbeeld een kerncentrale ontploft) doen we als softwaretesters óf een educated guess, óf we bepalen relatieve risico’s. Zo bepalen we door de bank genomen dat het risicovoller is dat een hacker losgaat op een site dan een potentiële taalfout op een willekeurige pagina. Anders gezegd: we doen echt niet aan kansberekening zoals we die ooit op de middelbare school hebben geleerd.
En als we ons dan laten verleiden tot pseudo-hardheid met cijfertjes betreffende kans en bijbehorende schade, dan lopen we een reëel risico de plank volledig mis te slaan.
Een voorbeeld: stel dat er in de sessie een schade-schaal wordt gebruikt van 1 tot 100. En dat de bovengenoemde potentiële schade van een succesvolle hack de waarde ‘100’ wordt gegeven (maximaal), en de kans op een succesvolle hack een ‘0,01’ (minimaal). De uiteindelijke score is dan ‘1’. Stel dat aan de schade door de taalfout een ‘1’ wordt toebedeeld (minimaal), en de kans daarop 0,999 (maximaal) is. Daarmee is ‘kans maal schade’-berekening voor beide gevaren zo goed als gelijk, met aldus een ‘gewenste’ gelijkwaardige prioritering in de testinspanning. Ik ga ervan uit dat niet alleen mijn intuïtie dan begint te gillen dat er iets he-le-maal misgaat.

 

Nu ben ik een medewerker van een ambitieuze, en ook bescheiden testclub.

Dus heb ik een en ander opgezocht bij de grootheden van ons vak: TMAP, ISTQB, RST. TMAP roept dat risico “the chance of failure combined with the impact when a failure occurs” is. Een interessante uitspraak als je overweegt dat ‘impact’ taal-technisch zowel negatief als positief kan uitpakken. ISTQB zegt overigens min of meer hetzelfde.
Bij RST heb ik geen definitie van een risico gevonden, maar wél een definitie van RBT (Risk Based Testing), die mijn verwarring ten aanzien van het taalgebruik en begrip rondom risico’s compleet heeft gemaakt: “Een type softwaretesten dat functioneert als een organisatorisch principe dat wordt gebruikt om de tests van functies en kenmerken in software te prioriteren, op basis van het risico op falen, de functie van hun belang en de waarschijnlijkheid of impact van falen.”[1][2]. Lees deze omschrijving nog eens, en mail me dan wat jij denkt dat er staat. Ikzelf vermoed het volgende: “RBT is het prioriteren van softwaretests op basis van risico's.” Maar, toegegeven, het blijft een gok.

Waar gaat het nou eigenlijk om?

Ik laat de definities, vergelijkingen en berekeningen los en keer terug naar de kern: wat zijn risico’s nou wezenlijk? In de basis worden softwaretesters betaald om ervoor te zorgen dat de kenmerken en eigenschappen van software overeenkomen met de verwachtingen van de klant. Dat is kwaliteit.
Zijn risico’s dan niet gewoon zorgen dat er in relatie tot die verwachtingen allerlei nare dingen kunnen gebeuren? Dat je als klant wel een auto wil die 300 kilometer per uur haalt, maar je zorgen maakt dat het wel eens het einde van je bestaan zou kunnen zijn bij de eerste de beste haarspeldbocht? En dat je als tester die zorgen onderzoekt, zodat er mitigerende en preventieve maatregelen kunnen worden genomen? En dat een risico-sessie niet meer is dan het stellen van de vraag wat de zorgen zijn, en waar we ons meer, en minder zorgen over maken? Dat het dus eigenlijk een ‘waar maken we ons (de meeste) zorgen over?’-sessie is, waarbij aangetekend mag worden dat een goeie sessie de realiteit van die zorgen inschat, indien nodig op zoek gaat naar de root cause en vast een eerste stap richting maatregelen doet, zoals het plannen van extra testinspanning bij grote zorgen?

Ik denk van wel.

De “waar maken we ons zorgen over – sessie” is de werktitel van een onderdeel van het Agile Test Model (en methode) die De Agile Testers in de loop van 2025 presenteren. De bedoeling is dat het model onderscheidend gaat werken, waardoor er in de ervaren huidige wildgroei rond het vak van softwaretesten duidelijkheid gaat ontstaan over het waarom, hoe en wat van softwaretesten, en dus ook wat het niet is.

 

[1] Bron: James Bach “De uitdaging van ‘goed genoeg’ software”, Cem Kamer & James Bach “The nature of Exploratory Testing”.

[2] En nee, het Engelse origineel wijkt niet significant af van de Nederlandse vertaling.

Naar het overzicht