Een nieuw project en een sessie Risk Storming

Auteur: Annemarie Doran-Collijn – adoran@mirabeau.nl
Redacteur: Rob van Steenbergen – rob@chickenwings.nl

Aan het begin van dit jaar kwam ik als vervangend scrummaster bij een voor mij nieuw team. Hier ging nog wel wat mis in communicatie en werkwijze. Er waren onduidelijkheden over wat er precies verwacht werd. Er werd vooral heel hard gerend. Omdat er nog geen teststrategie was, werd een van mijn taken naast scrummaster het opzetten van de teststrategie.

TestSphere kaarten
Een paar jaar geleden is via Ministry of Testing een set kaarten uitgebracht die kunnen helpen bij het praten over testen, de TestSphere kaarten. Deze kaarten zijn verdeeld in vijf categorieën: kwaliteitsaspecten, heuristieken, gevoelens, patronen, en technieken. Er zit een uitleg bij de kaarten waarop staat hoe je de kaarten kunt gebruiken als gespreksstarter en als een spel, waarbij het de bedoeling is om zoveel mogelijk kaarten in je bezit te krijgen.

De kaarten reisden al een flinke tijd met me mee in mijn tas toen ik er achter kwam dat iemand hiermee een spel had bedacht. Een spel waarmee je met behulp van gamification risico’s in een project in kaart kunt brengen: “Risk Storming”. Het doel van het spel is om risico’s in kaart te brengen aan de hand van de voor jou meest belangrijke kwaliteitsaspecten. Dit leek mij erg interessant en ik wilde dit al een tijd uitproberen. Het project waar ik bij aangesloten was leek me dan ook een goede kandidaat om dit uit te proberen.

Omdat het project al bijna een jaar bezig was voordat ik aansloot, wisten de ontwikkelaars veel beter wat er gaande was, dan ik daar achter zou kunnen komen door het lezen van de documentatie. Zij kenden ook de risico’s van het project. Het leek mij daardoor slim om hen uit te nodigen voor een sessie Risk Storming, en op die manier de risico’s in kaart te brengen.

Dit zou mij helpen een goede teststrategie op te zetten en misschien konden we meteen wat verbeteringen in de processen en werkwijzen aankaarten. Na wat speurwerk op internet kwam ik uit bij een website met duidelijke informatie over hoe je een sessie kunt inrichten, te beginnen met het printen van het spelbord. Dit was nog even gedoe met knippen en plakken omdat we geen printer hadden staan die groot genoeg was.

De sessie met de ontwikkelaars
Op de dag van de sessie stond ik klaar met voldoende post-it’s, sharpies, een timer en mijn TestSphere kaarten. In de eerste ronde hebben we de meest belangrijke kwaliteitsaspecten gekozen, gebaseerd op de kwaliteitskaarten uit het spel. Op het spelbord zijn hiervoor zes vakjes. Hier moesten keuzes in gemaakt worden, wat nog wel tot discussie heeft geleid. Ik denk dat zes kwaliteitsaspecten om op te focussen ook wel meer dan genoeg is voor zo’n sessie.

Het benoemen van risico’s was de tweede ronde van het spel. Hiervoor schreef iedereen op post-it’s wat men dacht welke risico’s er waren voor het project, in relatie tot de gekozen kwaliteitseisen. Hier kwamen ontzettend veel ideeën naar voren, maar ook heel veel die niet per se met de applicatie te maken hadden, maar eerder met processen binnen het team en randvoorwaarden om te kunnen leveren. Alle risico’s werden op de daarvoor bestemde plek op het bord geplakt.

Nu de risico’s in kaart gebracht waren, konden we de kaarten er bij pakken en gaan kijken naar welke testtechnieken of heuristieken we konden gebruiken om de risico’s tegen te gaan of te voorkomen. Hiervoor kwamen de kaarten met technieken, patronen en heuristieken tevoorschijn. Dit gaf ook wat discussie, maar er waren voor bijna alle risico’s oplossingen bedacht.

Aan het eind van de sessie was mijn energie wel op. Het is best intensief om zo lang over risico’s te praten. De feedback die ik kreeg was wel positief, men vond het leuk om op deze manier met het project bezig te zijn en zaken inzichtelijk te krijgen. Ik heb na afloop alle inzichten verzameld en verwerkt in een document, rondgestuurd naar mijn team en geen reactie op gekregen. De punten zijn meegenomen in mijn uiteindelijke teststrategie, maar die is niet helemaal hierop gebaseerd. Achteraf gezien was dit voor mij dus een leuke oefening, maar zowel ik en het team hebben hier weinig aan gehad.

Leerpunten
Het is belangrijk dat de deelnemers de kaarten kennen.
Dit maakt het makkelijker om ze te gebruiken en worden ze beter gebruikt. Nu zijn bepaalde oplossingen die gekozen waren heel anders geïnterpreteerd dan bedoeld. Misschien moet er eerst een sessie gepland worden om de kaarten te bespreken, of wellicht iedereen als voorbereiding vragen om er naar te kijken en vragen te stellen.

Het is verstandig om de klant uit te nodigen voor de sessie.
Deze ziet andere risico’s dan het team, beide ideeën aanhoren draagt bij aan beter begrip over wat er eigenlijk gebouwd moet worden.

Nog een sessie
Ondanks dat Risk Storming voor mij geen denderend succes is geweest, heb ik later nog een sessie gedaan met mijn testcollega’s. We hadden hiervoor onze bedrijfswebsite als systeem gekozen om in kaart te brengen. Met hen verliep de sessie een stuk soepeler. Ik kende de regels en opzet beter en zij kenden de technieken, patronen en heuristieken die gebruikt werden in het spel. Dat maakte het een stuk makkelijker.

Ik zou het zeker nogmaals inzetten om risico’s in kaart te brengen op een interactieve manier.

Links
RiskStorming – Maping Risks with TestSphere
Reinvent Your Test Strategy By RiskStorming With TestSphere.