Het VNSG Magazine, het vakblad voor alle SAP gebruikers in Nederland en Vlaanderen, verschijnt 5 keer per jaar. PTWEE geeft in iedere editie een praktische tip over testen in een SAP omgeving. Deze tip gaat over het baseren van de testaanpak op de risico’s.
Testen van wijzigingen in SAP omgevingen is nodig om verstoring van de business te voorkomen. Omdat de hoeveelheid tijd en geld voor testactiviteiten beperkt is moeten er keuzes worden gemaakt. De beste manier om dit te doen is met behulp van de ‘product risico analyse’. Dit is een goede methode om voor de verschillende systeemonderdelen risico’s te bepalen. Vervolgens worden daar afspraken over testen aan gekoppeld. Zo wordt het mogelijk om de meest risicovolle producten het beste en het eerste te testen. In projecten beperkt dit de druk op het kritieke pad.
Productrisico’s
In SAP projecten wordt veel gesproken over risico’s en het beperken van risico’s. Vaak wordt daarbij geen onderscheid gemaakt tussen productrisico’s en projectrisico’s. Projectrisico’s (en bijbehorende tegenmaatregelen) hebben betrekking op het project in zijn geheel. Productrisico’s hebben betrekking op de verschillende producten (systeemonderdelen) die door het project worden opgeleverd. Denk daarbij aan SAP modules, SAP transacties, rapportages en interfaces.
Een productrisico is te definiëren als de kans dat iets niet goed werkt (foutkans) maal de schade die wordt opgelopen als iets niet goed werkt (schade). Onderstaande afbeelding bevat een aantal voorbeelden van aspecten die van invloed zijn op de foutkans en een aantal voorbeelden van schade die een bedrijf kan lopen als gevolg van slecht werkende producten.
Wanneer het productrisico nul is dan is het niet nodig om te testen. In de volgende situaties is dat het geval:
- Foutkans is nul (nul x schade = nul)
- Schade is nul (foutkans x nul = nul)
Dit is natuurlijk theorie want in de praktijk is het productrisico nooit nul. Het maakt echter wel duidelijk waarom beide aspecten meegenomen moeten worden bij het uitvoeren van een ‘Product Risico Analyse’ (PRA).
PRA workshop
Een PRA workshop is een goede manier om met de betrokken partijen foutkans en schade voor alle producten vast te stellen. Voor het succesvol uitvoeren van een PRA workshop zijn de volgende zaken benodigd:
- Een overzicht van alle producten waarvoor risicoklassen worden bepaald (bijvoorbeeld SAP scenario’s, interfaces, rapportages, SAP transacties);
- Vertegenwoordiging vanuit IT (accent ligt op het geven van input voor de foutkans);
- Vertegenwoordiging vanuit de business (accent ligt op het geven van input voor de schade);
- Een procesbegeleider die ervoor zorgt dat er keuzes worden gemaakt in foutkans en schade en die voorkomt dat er oneindige discussies ontstaan.
Tijdens de PRA workshop wordt met elkaar, voor ieder product antwoord gegeven op de volgende twee vragen:
- Hoe groot is de kans dat deze functionaliteit niet werkt?
- Hoe groot is de schade als deze functionaliteit niet werkt?
Risicoklassen
Foutkans en schade worden per product bepaald en vervolgens leidt de combinatie van foutkans en schade tot een risicoklasse. Onze praktijkervaring is dat het verstandig is om het eenvoudig te houden en het aantal risicoklassen te beperken. In onderstaande matrix wordt gewerkt met risicoklasse hoog, midden en laag.
In deze matrix is schade belangrijker dan foutkans. Wanneer de schade laag is dan is de risicoklasse namelijk altijd laag. Ook als de foutkans hoog is.
Risk based plannen en werken
Wanneer de risicoklassen bekend zijn dan moet per risicoklasse worden bepaald hoe er wordt omgegaan met testen. Hoe hoger de risicoklasse, hoe beter er getest moet worden. Bijvoorbeeld:
Risicoklasse Testaanpak
Hoog: Testen op basis van gedetailleerde testscripts
Midden: Testen op basis van globale testcases
Laag: ‘Free format’ testen (dus zonder testscripts of vooraf opgestelde testcases)
Daarnaast zijn de risicoklassen leidend bij het plannen van de testwerkzaamheden en bij voorkeur ook bij het plannen van de ontwikkelwerkzaamheden. Vaak wordt in projecten onder druk van tijd en/of geld ingeleverd op de testwerkzaamheden (en daarmee op kwaliteit). Risk based plannen en werken vergroot de kans dat er uiteindelijk niet wordt ingeleverd op kwaliteit van producten met een hoge risicoklasse.
Wanneer wordt gewerkt met een externe implementatiepartner dan heeft het de voorkeur om de ontwikkel- en testwerkzaamheden van die partner ook risk-based uit te voeren. Op die manier worden de prioriteiten van de implementatiepartner voor een groot deel bepaald door de klant. Daarnaast hebben de risicoklassen grote invloed op de prioriteitstelling m.b.t. het oplossen van defects die uit een testproces naar voren komen.
Risk-based testen is één van de belangrijkste pijlers van een gestructureerd testproces. Misschien lijkt het lastig om dit in de praktijk te brengen maar dat valt erg mee zolang er pragmatisch mee om wordt gegaan en wordt voorkomen dat het een doel op zich wordt. Doelstelling is om een maximale testdekking te bereiken met beperkte middelen.
