Zo’n tien jaar geleden is risk based testen in de markt gezet. In die tijd was dit een geweldig nieuwe stap in de ontwikkeling van het testvak. Een van de onderdelen van risk based testen is de productrisico-analyse (pra). Een algemeen geaccepteerd uitgangspunt om onder meer de teststrategie op te baseren. Echter, waar loop je tegenaan in de praktijk bij de toepassing van pra's?
Risk based testen heeft na de introductie (‘Succesvol Testmanagement: een integrale aanpak’, Bob van de Burgt, Iris Pinkster, 2003) navolging gekregen in vele andere methoden (‘Practical Risk-Based Testing’, Erik van Veenendaal, 2012; ‘TMap Next’, Tim Koomen, Leo van der Aalst, Bart Broekman, Michiel Vroon, 2006; ‘SmarTEST’, Egbert Bouman, 2008). Iedereen praat tegenwoordig over de productrisico analyse en het gebruik ervan wordt als gemeengoed ervaren.
De toepassing van productrisico’s gaat tegenwoordig veel verder dan alleen het in kaart brengen van de productrisico’s. Is er bijvoorbeeld geen testbasis? Dan gebruiken we, als testers, de aanpak van productrisico’s om een testbasis te genereren. Het goed toepassen van productrisico’s is geen sinecure. Het gaat niet alleen om zoveel mogelijk productrisico’s te verzamelen maar verzamel je de juiste, met voldoende kwaliteit, zijn alle relevante partijen betrokken, zijn geen gebieden vergeten? Wordt de productrisico vertaald naar een gedragen teststrategie en sluit de testrapportage aan bij de productrisico’s? Onderwerpen waar niet te lichtzinnig over gedacht moet worden.
Dit artikel beschrijft een aantal ervaringen in de toepassing van productrisico’s. Waar kun je tegen aan lopen en wellicht nog interessanter. Hoe kun je het oplossen?
Selectie van stakeholder
Een stap waar geregeld lichtzinnig over wordt gedacht betreft de selectie van de stakeholder. Afhankelijk van de omvang en doelstelling van het project kunnen er veel stakeholders betrokken zijn. Een zorgvuldige analyse is op zijn plaats. Geregeld worden doelgroepen vergeten. Denk bijvoorbeeld aan de beheer afdeling en audit dienst. Zonder deze stakeholders zal de productrisico niet compleet zijn, met als gevolg dat de teststrategie niet dekkend is.
De kans is groot dat de teststrategie niet geaccepteerd wordt en uiteindelijk worden de eindrapporten niet geaccepteerd. Een simpele, maar krachtige, oplossing is om aan de hand van het bedrijfsproces in kaart te brengen wie welke stappen in het bedrijfsproces uitvoeren. Deze partijen zijn dan een vereiste in de workshop. Los van deze partijen zijn er een aantal groepen die altijd betrokken moeten zijn zoals beheer, auditdienst, projectmanagement en niet te vergeten de opdrachtgever.
Te generiek
Tijdens de workshop gebeurt het regelmatig dat de productrisico’s te generiek zijn opgesteld. Een voorbeeld: functioneel beheer is niet mogelijk. Altijd waar, maar wat bedoelen we hiermee? Is monitoring niet mogelijk of het opvoeren van nieuwe gebruikers? Voor test kunnen we hier geen adequate testgevallen voor ontwikkelen. Of de testgevallen zijn te hoog over of we slaan de plank mis of we missen simpelweg delen. In de workshop moet je als moderator hier actief op sturen.
Afhankelijk van de vorm die je kiest zal je de deelnemers continu een spiegel voorhouden met vragen als: wat bedoel je hiermee, hoe kun je dit aantonen, wie heeft er last van? Situaties voorstellen, deelnemers prikkelen en kijken of je testgevallen voor het betreffende productrisico kunt ontwikkelen. Door het stellen van dit soort vragen krijg je een lijst met smart risico’s, waarmee je de vervolgstappen goed kunt inrichten. Met vervolgstappen wordt hier het opstellen van de daadwerkelijke teststrategie bedoeld. Daarnaast kunnen er adviezen volgen aan het project ter voorkoming van productrisico’s. Heb je als testmanager de modererende rol dan kun je hier het verschil maken! In een testbasis die SMART is en een slechte (niet SMART) testbasis waarbij je in de uitwerking continu vragen moet stellen hoe zaken echt in elkaar steken.
Scope te beperkt
De scope van de productrisico analyse ligt regelmatig alleen op de wijzigingen die doorgevoerd worden. Wat is de impact indien de focus alleen op de wijzigingen ligt? Dit fenomeen zie je vooral bij releasematig werken. Uiteraard ligt de nadruk op het vaststellen van de product risico’s die mogelijk geïntroduceerd worden door de betreffende wijziging. Dat is stap één. Echter, indien een bestaand bedrijfsproces wordt aangepast dan moet je ook vaststellen welke bestaande productrisico’s als regressie meegenomen dienen te worden.
Wat is de impact indien de focus alleen op de it ligt? Veelal worden de productrisico’s vanuit het bedrijfsproces opgesteld, gerelateerd aan het informatiesysteem. Een voorbeeld is: ‘het niet kunnen afsluiten van een order boven de vijfduizend euro’. Dit kun je vaststellen door het uitwerken van een aantal testgevallen. Echter de laatste jaren komt de focus, naast de it, ook steeds meer te liggen op de organisatiegereedheid en de procesinrichting. Dat heeft tot gevolg dat niet alleen it-gerelateerde productrisico’s opgesteld worden maar ook productrisico’s die de organisatie en het bedrijfsproces afdekken. Daarbij kun je bijvoorbeeld denken aan: ‘Gebruiker is niet in staat om met het nieuwe/gewijzigde informatiesysteem te werken.’ Om dit productrisico goed te kunnen afdekken dien je wellicht andere risico bestrijdende maatregelen te bedenken dan de traditionele. Denk bijvoorbeeld aan het uitvoeren van een procesverificatietest of een simulatiesessie.
Prioritering
Een van de resultaten van de workshop is de prioritering van de productrisico’s. De stakeholders vinden hun productrisico het allerbelangrijkste en veelal zie je dat deze dan de prioriteit ‘hoog’ krijgen. Vaak is de impact van een dergelijke toekenning niet duidelijk. De testinspanning zal groter zijn, er zullen meer risico beperkende maatregelen nodig zijn en wellicht zijn er meer resources nodig. Voor een goede prioriteitstelling kan de moderator vragen stellen als; wie heeft er last van? Hebben al onze klanten er last van of een beperkte groep?
Wat is de omvang van de populatie die geraakt wordt door het productrisico en wat is de imagoschade, zijn vragen die de moderator kan stellen om de juiste prioriteit te bepalen. Een andere mogelijkheid is gebruik te maken van het zogenaamde dot voting-mechanisme. Iedere deelnemer krijgt drie stickers die men bij de, in de ogen van de stakeholder, belangrijkste productrisico’s mag plakken. De productrisico’s met de meeste stickers krijgen de prioriteit hoog.
Werkvorm
Een goede werkvorm is het halve werk. Dat is ook van toepassing voor de productrisico workshop. Naast de eerder genoemde selectie van stakeholders is het bepalen van de juiste aanpak van groot belang. Daarbij is het type deelnemer het uitgangspunt. Zijn er introverte deelnemers, kies dan voor een actieve werkvorm in plaats van bijvoorbeeld een klassikale werkvorm. Een actieve werkvorm is bijvoorbeeld de totale groep op te splitsen in tweetallen en in carrouselvorm door te laten draaien naar bijvoorbeeld het volgende bedrijfsproces.
Zo stimuleer je iedere deelnemer tot het genereren van productrisico’s. Tijdens de inrichting van de werkvorm speelt ook mee op welk niveau de productrisico’s verzameld gaan worden? Op bedrijfsprocesniveau of systeemcomponenten of bijvoorbeeld op functionaliteit. Een tip daarbij is te kijken naar de doelstellingen van het project of de release. Heeft het project te maken met een herinrichting van de business dan is het handig de productrisico’s te verzamelen op bedrijfsprocesniveau. De moderator zal zich in de voorbereiding moeten verdiepen in de materie en vragen verzamelen die kunnen leiden tot mogelijke productrisico’s. Deze vragen kan de moderator gebruiken op het moment dat de creativiteit stokt, om de deelnemers weer te inspireren tot het genereren van nieuwe productrisico’s.
Het vervolg
Wat je veel ziet is dat de productrisico’s worden opgesteld, teruggekoppeld en opgenomen in een test plan. Veelal blijft het daarbij. Dat doet onrecht aan de kracht van productrisico’s. De productrisico’s vormen een perfecte basis voor rapportage. Richt je testproces zo in (creatie testgevallen) dat op basis van de productrisico’s gerapporteerd wordt naar alle stakeholders. Deze kunnen dan de kwaliteitsontwikkeling op de voet volgen. Uiteindelijk kan het de basis vormen voor het vrijgave advies en de sturing van de implementatie. Immers, door het gebruik van productrisico’s krijg je inzichtelijk wat de aandachtspunten zijn. Deze informatie kun je gebruiken om workarounds in te richten en de helpdesk c.q. het beheer te informeren en voor te bereiden. Kort door de bocht gesteld: Wil je als testmanager de productrisico’s niet op deze wijze verwerken en gebruiken in je testproces, voer dan geen workshop uit en gebruik de productrisico’s dan vooral niet.
Met dank aan mijn collega’s Hans Ruesink en René Lak.
