Riskbased testen binnen een SCRUM-team

Deze aanpak heeft geleid tot een reductie van het aantal patches dat op elke release gedaan moest worden en tot meer kwaliteitsbewustzijn binnen het scrum-team.

Aangezien klanten vaak op korte termijn (soms wettelijke) aanpassingen in deze hypotheekapplicatie gerealiseerd willen hebben, wordt in het ontwikkelteam gewerkt volgens de SCRUM-methodiek. In sprints van gemiddeld twee weken worden de meest urgente wijzigingen gerealiseerd en opgeleverd. Het scrum-team, dat bestaat uit modelleurs, een programmeur en een testspecialist, bepaalt aan het begin van elke sprint, in overleg met de Product Owner, wat er opgepakt kan worden in de volgende sprint.

Om binnen de beperkte tijd van elke sprint de stories van voldoende kwaliteit te voorzien, is Risk Based testen geïntroduceerd. De stories in een sprint worden niet alleen qua grootte op punten geschat, maar ook op risico. Voor dit laatste wordt tijdens de sprintplanning gekeken wat de kans is dat er iets fout gaat tijdens de bouw. Hiervoor brainstormen alle teamleden over eventuele technische risico’s die zij zien bij het realiseren van een user story. Vervolgens wordt er op basis van deze informatie een kleur gekozen, van groen (geen tot nauwelijks risico) oplopend tot rood (groot risico). Wanneer hier consensus over is bereikt en de Product Owner op dezelfde manier het risico (middels dezelfde kleurenreeks) heeft bepaald voor de business-impact van eventuele fouten, ligt de testinspanning voor elke userstory vast. Deze testinspanning, voor zowel unit testen als systeemtesten, bestaat uit testtechnieken met bepaalde dekking, die worden opgepakt en uitgevoerd door elk willekeurig teamlid. De unittesten worden hierbij geautomatiseerd en na elke nieuwe build opnieuw gedraaid.