Leiderschap in testen: risicogestuurd testen
Noot van de redactie: Welkom bij de serie Leiderschap in testen van softwaretestgoeroe en consultant Paul Gerrard. De serie is bedoeld om testers met enkele jaren ervaring—vooral degenen in agileteams—te helpen uitblinken in hun rollen als testleider en manager.
In het vorige artikel keken we naar het belang van testmodellen. Hier gaan we dieper in op het concept risico en bieden we een manifest voor risicogestuurd testen dat je kunt toepassen op je eigen methode voor risicogestuurd testen.
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te ontvangen wanneer nieuwe delen van de serie verschijnen. Deze berichten zijn uittreksels uit Pauls cursus Leiderschap in testen, die we sterk aanbevelen als je dieper op dit en andere onderwerpen wilt ingaan. Als je dat doet, gebruik dan onze exclusieve kortingscode QALEADOFFER en ontvang $60 korting op de volledige cursusprijs!
Risico’s hebben, als ze werkelijkheid worden, een nadelig effect op onze projecten. Risicobeheer houdt in dat je nadenkt over welke risico’s bestaan en maatregelen neemt om de waarschijnlijkheid ervan te verkleinen, ze uit te sluiten of de impact ervan op de doelstellingen van onze belanghebbenden te verminderen.
In sommige bedrijven wordt risicobeheer met technische en wiskundige precisie uitgevoerd. In software is het niet mogelijk om zeer nauwkeurig te zijn. De meeste organisaties passen risicogestuurd testen nog steeds niet systematisch toe. Daar is echter een goede reden voor: zodra softwareproductrisico’s zijn geïdentificeerd, zijn ze vaak buitengewoon moeilijk te beoordelen.
Vanuit het perspectief van testen en kwaliteitsborging is een risico een ‘faalwijze waarover zorgen bestaan’. Risicogestuurd testen is het modelleren van potentiële faalwijzen van systemen als productrisico’s ter ondersteuning van de afbakening, opschaling en prioritering van tests.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
In dit artikel bied ik een manifest voor risicogestuurd testen. We bekijken klassiek risicobeheer en zien hoe we dit kunnen aanpassen zodat het bruikbaar is voor testers. Tot slot kijken we naar enkele praktische aspecten en overwegingen die je helpen om je eigen risicogestuurde testmethode toe te passen.
- Project-, proces- en productrisico
- Een manifest voor risicogestuurd testen
- De klassieke benadering van risico
- Productrisico en testen
- Praktische aspecten
- De rol van testen in risicobeheer begrijpen
We gebruiken deze definitie van risico: Een risico is een bedreiging voor een of meer doelstellingen van de belanghebbenden van een project en heeft een onzekere waarschijnlijkheid.
Project-, proces- en productrisico
Er zijn honderden boeken over risico en risicobeheer waarin talloze benaderingen voor het beheren van risico’s op projectniveau worden uiteengezet. Deze benaderingen richten zich doorgaans op wat we project- en procesrisico’s zullen noemen, met misschien één risico met een titel als ‘niet voldoen aan de vereisten’. Eén vereistenrisico is niet erg nuttig, want het is niet zo dat je één risico voor het testen kunt prioriteren.
Er zijn drie soorten software risico’s.
Projectrisico: Deze risico’s hebben betrekking op het project binnen zijn eigen context. Projecten hebben doorgaans externe afhankelijkheden, zoals de beschikbaarheid van vaardigheden, afhankelijkheid van leveranciers, vaste deadlines of beperkingen zoals een contract met een vaste prijs. Externe afhankelijkheden vallen onder de verantwoordelijkheid van projectmanagement.
Procesrisico: Deze risico’s hebben voornamelijk betrekking op de interne aspecten van het project; de planning, monitoring en beheersing van het project worden hierbij onder de loep genomen. Typische risico’s zijn een onderschatting van de complexiteit van het project, de benodigde inspanning of de vereiste vaardigheden. Het interne beheer van een project, zoals een goede planning, voortgangsmonitoring en beheersing, valt volledig onder de verantwoordelijkheid van projectmanagement.
Productrisico: Productrisico is het belangrijkste risicogebied voor testers. Deze risico’s hebben betrekking op de definitie van het product, de stabiliteit (of het gebrek daaraan) van de vereisten, de complexiteit van het product en de foutgevoeligheid van de technologie.
Vanaf nu concentreren we ons op productrisico’s. We gebruiken de term productrisico als volgt:
Een productrisico vertegenwoordigt een faalwijze of een faalpatroon dat onaanvaardbaar zou zijn in een productieomgeving.
Een manifest voor risicogestuurd testen
In projecten waarin risico’s worden genomen (wat volgens ons bij alle projecten het geval is), moeten testers de risico’s zichtbaar maken voor het management en betrouwbare testmethoden voorstellen om deze risico’s gedurende het hele project aan te pakken.
Dit is de managementtaak: de volgende taken voor risicogestuurd testen uitvoeren en/of erop toezien:
De klassieke benadering van risico
Er zijn veel variaties, maar de klassieke benadering van risico probeert kwantitatief te zijn.
Waarschijnlijkheid, gevolg en blootstelling
Om een productrisico te beoordelen, moeten we begrijpen wat het gevolg is van die faalwijze. Als er een fout optreedt, zeggen we dat het risico zich manifesteert. Vervolgens vragen we: “hoe ernstig is het risico?”, ook wel blootstelling genoemd.
Om de blootstelling vast te stellen, beoordelen we het risico aan de hand van twee dimensies:
- De waarschijnlijkheid (of kans) dat een risico zich manifesteert. Deze waarde wordt doorgaans uitgedrukt als een percentage tussen (maar exclusief) nul en 100 procent.
- Het gevolg (of de impact of het verlies) wanneer een risico zich manifesteert. Dit zijn de potentiële kosten van de schade als deze faalwijze optreedt.
De blootstelling van een risico – hoe ernstig een risico is – wordt berekend als het product van de waarschijnlijkheid en het gevolg.
Blootstelling = waarschijnlijkheid van het risico X gevolg van het risico.
De klassieke benadering van risico beschikt vaak niet over de technologische ondersteuning die nodig is voor efficiënt beheer. Moderne oplossingen voor testbeheer vullen deze leemte op door functies aan te bieden die zijn afgestemd op risicogebaseerd testen.
Kwantitatieve of kwalitatieve beoordeling
Het is vaak moeilijk om de potentiële kosten van een fout te voorspellen. Zonder verdere informatie is het ook vrijwel onmogelijk om de waarschijnlijkheid van een fout met enige zekerheid te voorspellen. Daarom hanteren de meeste professionals semi-kwantitatieve of kwalitatieve schalen voor waarschijnlijkheid en gevolg.
Het is gebruikelijk om voor beide schalen numerieke bereiken van één tot vijf te gebruiken, wat mogelijke waarden voor blootstelling van één tot vijfentwintig oplevert. Maar weinig testers, ontwikkelaars of belanghebbenden kennen deze getallen met enige zekerheid toe. Daarom is het gebruikelijk om de risicoblootstelling rechtstreeks te beoordelen op een schaal van 1 tot 5, of — nog eenvoudiger — met een beoordeling in rood, oranje en groen. Sommigen gaan zo ver dat ze simpelweg zeggen dat risico’s binnen of buiten de scope vallen, maar wij zouden dit een te vergaande vereenvoudiging noemen.
Of je de risico’s in de tabel kwantificeert of met kleuren codeert, het cruciale aspect van risicobeoordelingen is niet de score, maar de gesprekken en discussies die je voert bij het toekennen en bespreken van de scores.
Om Eisenhower verkeerd te citeren: het risicoplan is niets, risicoplanning is alles.
Als je wordt gevraagd om risico’s met meer precisie te scoren dan met schalen van één tot drie (of hooguit vijf), moet je serieus overwegen of de getallen die je toekent enige werkelijke waarde hebben.
Numerieke scores kunnen een indruk van wetenschappelijke nauwkeurigheid wekken, maar als de getallen giswerk zijn, houd je jezelf voor de gek. Als getallen verschillen van mening aan het licht brengen, bijvoorbeeld wanneer een gebruiker “vijf” zegt en de ontwikkelaar “één!”, dan is daarover een gesprek nodig, omdat de verwachtingen of percepties duidelijk verschillen.
Pas op met het gebruik van een eenvoudige regeling voor risico’s die binnen of buiten de scope vallen. Het kan duidelijk zijn welke zorgwekkende risico’s door testen moeten worden aangepakt. Projecten leren echter in de loop der tijd en lopen vaak vertraging op, waardoor compromissen moeten worden gesloten. Als risico’s niet op een bepaalde manier worden geprioriteerd, moet je alle zorgwekkende risico’s opnieuw beoordelen om te bepalen welke mogelijk uit de scope moeten worden verwijderd of eraan moeten worden toegevoegd.
In volgende artikelen bespreken we scopebepaling, prioritering en opschaling uitgebreider, dus blijf ons volgen.
Productrisico en testen
De bespreking van (product)risico’s brengt de zorgen van belanghebbenden over de waarschijnlijkheid van fouten in kritieke onderdelen van het project of systeem aan het licht. Gegeven een lijst met productrisico’s: hoe vertalen we die naar acties en specifieke testplannen? Voordat we die vraag kunnen beantwoorden, moeten we iets beter begrijpen hoe testen onze risicobeoordelingen beïnvloedt.
Testen vermindert het risico niet – het informeert risicobeoordelingen
Je hoort mensen vaak zeggen dat ‘testen het risico vermindert’. Dat is niet waar — testen kan het risico soms vergroten. De mantra dat testen het risico vermindert, komt voort uit een gebrek aan inzicht in zowel risico’s als testen.
Stel dat we een risico hebben geïdentificeerd dat een bepaalde functie of functionaliteit kan falen. We formuleren een test en voeren die uit. De test kan slagen of mislukken. Welke invloed zou het slagen of mislukken van een test hebben op onze risicobeoordeling?
Ten eerste hebben tests geen invloed op ons begrip van het gevolg van een fout. Het gevolg van een fout is wat het is en testen verandert daar niets aan.
Er zijn vier relevante uitkomsten van een test en de impact daarvan op de risicowaarschijnlijkheid. Deze worden samengevat in deze tabel:
| Risicowaarschijnlijkheid neemt toe | Risicowaarschijnlijkheid neemt af | |
| Test slaagt | Nee. Een geslaagde test kan ons alleen meer vertrouwen geven dat een faalwijze niet zal optreden. (Dit veronderstelt dat onze tests betekenisvol zijn.) | Ja, uiteindelijk. Naarmate we steeds meer tests uitvoeren die slagen en uiteenlopende scenario's verkennen, neemt de waarschijnlijkheid van falen af. |
| Test faalt | Mogelijk, afhankelijk van de fout. Maar de waarschijnlijkheid neemt in de loop van de tijd af. We voorspelden dat deze faalwijze zou optreden; onze testkeuze wordt bevestigd. Gelukkig kunnen we dit nu oplossen en onze tests richten op het verminderen van het risico op andere fouten van dit type. | Niet waarschijnlijk, tenzij onze risicoanalyse onjuist was. |
Door tests uit te voeren die we in verband brengen met een bepaald risico, krijgen we steeds meer informatie om onze risicoanalyse te verfijnen. Als tests mislukken, wordt onze keuze bevestigd. Wanneer we het probleem oplossen en opnieuw testen, zou onze risico-inschatting moeten afnemen naarmate de tests slagen. Maar als we steeds nieuwe of meer bugs vinden, kunnen we het risico opnieuw beoordelen als hoger.
Denk hier eens over na: als je een test uitvoert en de uitkomst je waarschijnlijkheidsinschatting in geen van beide richtingen beïnvloedt, is het waarschijnlijk een waardeloze test.
Nu je begrijpt hoe tests onze risicoanalyse kunnen informeren, kunnen we kijken naar het specificeren van tests aan de hand van risicobeschrijvingen.
Risicogebaseerde testplanning
Als testers moeten we, zodra we een productrisico hebben geïdentificeerd dat onze aandacht vereist, een reeks tests opstellen die aantonen dat die faalwijze minder waarschijnlijk is. Uiteraard zullen we proberen de faalwijze op zoveel mogelijk manieren te stimuleren en daarbij doen we een van de volgende dingen:
- We ervaren fouten, detecteren bugs en lossen deze op (waardoor het risico op die faalwijze afneemt), of
- We behalen geslaagde tests en ons vertrouwen dat een faalwijze minder waarschijnlijk is, neemt toe.
Gezamenlijk richten onze tests zich op manieren waarop een geselecteerde faalwijze kan optreden. Stel bijvoorbeeld dat het risico ‘het niet correct berekenen van een motorrijverzekeringspremie’ was. In dit geval zou een passend testdoel kunnen zijn: ‘aantonen dat het systeem met behulp van de all-pairs-techniek voor invoervariabelen de motorrijverzekeringspremie correct berekent’. Dit testdoel kan aan een tester worden gegeven om bijvoorbeeld met behulp van all-pairs een allesomvattende set testgevallen af te leiden.
Praktische aspecten
Nu enkele praktische overwegingen rond risicogebaseerd testen.
Wat als belanghebbenden niet geïnteresseerd zijn in hulp bij de risicoanalyse?
Het kan lastig zijn om tijd van belanghebbenden te krijgen om je te helpen risico's te identificeren en te beoordelen en je testplan op te stellen.
Wat als er meerdere testopties zijn voor een productrisico?
Dat is natuurlijk vrijwel altijd het geval. Om bijvoorbeeld een zorgwekkende functie te testen, kun je een van verschillende testontwerptechnieken gebruiken, of de functie modelleren op een unieke manier en tests uit dat model afleiden. Er zijn verschillende dekkingsmaatstaven die je kunt gebruiken om een doel vast te stellen. Je kunt een functie handmatig testen of met behulp van een tool of andere technologie.
In het volgende artikel, ‘Hoeveel testen is genoeg?’, bekijken we hoe je keuzes kunt maken.
Wat als testen (om een risico aan te pakken) te veel kost?
Omdat er vrijwel altijd opties zijn en er geen limiet is aan de hoeveelheid testen die je kunt uitvoeren om een risico te onderzoeken en een risicoanalyse te onderbouwen, moet er een keuze worden gemaakt. Het spreekt voor zich dat sommige opties als te duur worden beschouwd. Wanneer je opties aan belanghebbenden presenteert, moet je daarom ten minste één betaalbare optie en één mogelijk onbetaalbare optie hebben.
Nogmaals: in het volgende artikel, ‘Hoeveel testen is genoeg?’, bekijken we hoe je keuzes kunt maken.
Als we functies met een hoog risico uitgebreider testen, testen we andere functies toch minder?
Als het testbudget voor een team vooraf is vastgesteld of de teamgrootte en het aantal testers vastliggen, is de hoeveelheid testen die mensen kunnen uitvoeren beperkt (binnen een bepaalde tijdschaal of tijdgebonden periode). Als we dus meer nadruk leggen op bepaalde functies, moeten de tests van andere functies worden verminderd. De dekking, of op zijn minst de inspanning per functie, varieert met het risico.
Je kunt dit als volgt bekijken: wanneer een test faalt en er een bug in het systeem wordt gevonden, houdt de ernst die aan de bug wordt toegekend waarschijnlijk nauw verband met het gevolg van die fout (in productie). Ernstigere bugs worden opgelost omdat ze voor belanghebbenden simpelweg belangrijker zijn.
Een productrisicoanalyse benadrukt de gebieden waar bugs, omdat ze belangrijk zijn, waarschijnlijker worden opgelost. Door een risicoanalyse te gebruiken om te bepalen waar wordt getest en/of waar meer tests worden uitgevoerd, is de kans groter dat we belangrijke bugs vinden en kleiner dat we bugs vinden in functies waar belanghebbenden mogelijk minder waarde aan hechten.
Het zou mooi zijn om te denken dat we soms overal op een gelijkmatigere manier kunnen testen. Maar wanneer middelen en tijd beperkt zijn (en dat zijn ze altijd, toch?), helpt een risicogebaseerde aanpak je om de tijd van testers effectiever en efficiënter te benutten.
Wat als testen niet de juiste reactie is?
Voordat je tijd besteedt aan het gedetailleerd uitwerken van een testaanpak voor een productrisico, is het belangrijk om ook opties zonder testen te overwegen. Stel bijvoorbeeld dat er grote zorgen zijn dat een systeemcomponent in productie niet goed genoeg presteert en dat responstijden of betrouwbaarheid slecht zijn. Natuurlijk kun je belastingtests uitvoeren en proberen je uit de problemen te debuggen. Maar andere opties kunnen zijn:
- Koop de component bij een 3e partij, bouw hem niet zelf en neem dat risico niet.
- Herontwerp de architectuur van de oplossing om belastingen over meerdere exemplaren van de component te verdelen.
- Verplaats de verwerking naar een batchsysteem op een kopie van de gegevens.
- Implementeer niet in één keer voor alle gebruikers, maar kies voor een gefaseerde aanpak waarbij klanten regio voor regio worden geïmplementeerd en de prestaties nauwlettend worden bewaakt.
- Enzovoort.
Vaak is een andere aanpak om te voorkomen dat problemen ontstaan effectiever en voordeliger dan testen om die problemen later op te sporen.
De rol van testen in risicobeheer begrijpen
Testen kan het risico van een release verkleinen. Als we een risicobeoordeling gebruiken om onze testactiviteiten te sturen, wordt het doel van testers expliciet om tests te ontwerpen die fouten opsporen, zodat deze kunnen worden hersteld en daarmee het risico van een gebrekkig product wordt verminderd.
Het opsporen van fouten vermindert het restrisico op storingen tijdens livegebruik, waar de kosten zeer sterk toenemen. Wanneer een test een fout vindt en deze wordt gecorrigeerd, neemt het aantal fouten af en daardoor neemt de algehele waarschijnlijkheid van een storing af.
Je kunt het ook op deze manier bekijken: het ‘microrisico’ dat door die fout wordt veroorzaakt, is geëlimineerd. Maar er moet aan worden herinnerd dat testen niet alle fouten kan vinden. Er zullen dus altijd latente fouten zijn die onaangeroerd blijven en waarover testen geen directe informatie heeft opgeleverd.
Als we ons echter richten op kritieke functies en daarin fouten vinden, zijn onopgemerkte fouten in deze kritieke functies minder waarschijnlijk. De fouten die achterblijven in de niet-kritieke functies van het systeem hebben minder ernstige gevolgen.
Tot slot nog dit: het proces van risicoanalyse is zelf riskant. Risicoanalyse kan risico’s zowel overschatten als onderschatten, wat leidt tot minder dan perfecte besluitvorming. Risicoanalyse kan ook bijdragen aan een schuldcultuur als je hierin te ver gaat.
Naast andere mogelijke valkuilen van risicoanalyse moet je begrijpen dat er niet zoiets bestaat als een absoluut risico dat na afloop van het project kan worden berekend. De aard van risico’s is dat ze onzeker zijn. Net als bij de effectiviteit van testen kan de waarde van een risicoanalyse alleen achteraf worden bepaald, nadat het project is afgerond.
En dat was ons manifest voor risicogebaseerd testen. Het concept zal in de hele serie Leiderschap in testen opnieuw terugkomen, dus houd ons in de gaten voor meer artikelen!
Schrijf je in voor de nieuwsbrief van The QA Lead om een melding te krijgen wanneer nieuwe delen van de serie verschijnen. Deze berichten zijn fragmenten uit Pauls cursus Leiderschap in testen, die we sterk aanbevelen voor een diepere duik in dit en andere onderwerpen. Gebruik in dat geval onze exclusieve kortingscode QALEADOFFER voor $60 korting op de volledige cursusprijs!
