Testen op basis van productrisico’s

Omdat softwarefouten grote gevolgen kunnen hebben voor uw bedrijfsvoering, is het noodzakelijk om wijzigingen en IT projecten goed te testen. Gezien de beperkte hoeveelheid tijd en geld voor het testen, dienen er keuzes te worden gemaakt. Omdat niet het vinden van fouten, maar vooral het afdekken van risico’s belangrijk is bij testen, kunnen deze keuzes het beste gemaakt worden op basis van een product risico analyse (PRA).

Middels de PRA wordt aan ieder systeem- of procesonderdeel (de 'producten') een risicolabel gekoppeld. Per risicolabel wordt vervolgens een eigen testaanpak bepaald. Hierdoor wordt de druk op het kritieke pad beperkt en worden de meest risicovolle onderdelen het meest diepgaand en als eerste getest.

Projectrisico of productrisico?

Tijdens een project worden projectrisico’s en productrisico’s ten onrechte door elkaar gebruikt, terwijl het twee totaal verschillende zaken zijn. Wanneer de risico’s betrekking hebben op het gehele project (bijvoorbeeld 'onvoldoende resources voor testen i.v.m. vakantieperiode'), dan zijn dit projectrisico’s. Er wordt pas gesproken over productrisico’s wanneer de risico’s direct betrekking hebben op de verschillende te realiseren systeem- of procesonderdelen (producten).

Omdat zelfs een klein project betrekking kan hebben op een groot aantal producten, is het belangrijk om overzicht te houden over de producten. Het opstellen van een boomstructuur met alle producten is een handige manier om de producten weer te geven. Deze boomstructuur dient vervolgens als uitgangspunt voor de PRA.

Een voorbeeld boomstructuur ziet er als volgt in Testersuite uit:

‍

‍

‘Foutkans maal schade’

De kans dat een product niet goed functioneert noemen we de foutkans. De foutkans is groter wanneer een product grotendeels bestaat uit maatwerk programmatuur, als het product zeer veel wordt gebruikt of als het ondersteunde proces zeer complex is. Omdat betrokkenen vanuit de IT het meeste zicht hebben op deze aspecten, verzorgen zij idealiter de input met betrekking tot de foutkans. Het is belangrijk om ook de argumentatie hierbij te borgen.

De omvang en ernst van de (potentiële!) problemen die een niet goed werkend product veroorzaakt noemen we de schade. Voorbeelden van schade zijn imageschade, omzetderving of grote herstelkosten. Opdrachtgevers uit de business of andere betrokkenen uit de business bepalen de (bedrijfs)schade per product. Ook hier geldt dat het waardevol is om deze argumentatie vast te leggen.

Het resultaat is dat op productniveau de classificatie voor de foutkans, de toelichting daarop, de classificatie voor de schade inclusief toelichting en het uiteindelijke risico is vastgelegd:

‍

‍

Het spreekt voor zich dat beide aspecten in ogenschouw genomen moeten worden om het uiteindelijke risico te bepalen. Volgens de theorie in TMap bepaalt ‘foutkans maal schade’ de risico classificering, echter werkt in de praktijk een eenvoudige tabel beter dan een wiskundige benadering van risicobepaling:

‍

‍

De schade weegt vanzelfsprekend zwaarder dan de foutkans. Is de schade laag, dan is de kans op deze beperkte schade minder relevant. Het is verstandig om de indeling van risico’s beperkt te houden (zoals in bovenstaand voorbeeld Laag/Midden/Hoog), aangezien er per risicoklasse een andere testaanpak moet worden gehanteerd.

De meest effectieve manier om de PRA uit te voeren is in workshopvorm met alle betrokkenen uit IT en business. Om te voorkomen dat te lang wordt gediscussieerd is het aan te bevelen om een onafhankelijke begeleider van het proces de PRA sessie te laten begeleiden. Testersuite heeft veel ervaring in het begeleiden van dergelijke sessies.

Testaanpak op basis van risico’s

De risicoklassen zijn richtinggevend voor het plannen van de testspecificatie en –uitvoer. Het liefst worden ook de ontwikkelwerkzaamheden gepland op basis van dezelfde risico’s, waarbij de hoogste risico producten het eerste worden ontwikkeld. In projecten wordt er vaak, onder druk van tijd en/of geld, op de testwerkzaamheden ingeleverd. Om de kans te vergroten dat er niet wordt ingeleverd op kwaliteit van producten met een hoge risicoklasse, heeft het de voorkeur te plannen en te werken op basis van risico’s. De risicoklassen kunnen ook gebruikt worden voor het prioriteren van oplossen van defects, het opstellen van documentatie of afspraken met externe leveranciers. Bovendien draagt een PRA sessie bij aan de bewustwording met betrekking tot testen.

Door de testaanpak te baseren op productrisico’s wordt het mogelijk om de beschikbare testresources te besteden aan de belangrijkste zaken. Een PRA is bovendien zeer goed herbruikbaar in toekomstige testtrajecten, omdat met name de bepaalde schade niet snel veranderd. Het is hierbij belangrijk om de resultaten van een PRA goed vast te leggen. Testersuite biedt volledige ondersteuning bij het testen van risico’s en faciliteert bovendien het hergebruiken van risicoklassen.

‍