Kristel Beekmans en Thomas Vink - een Agile omgeving vraagt om een aangepast testproces. In onze vorige blog hebben we laten zien hoe we daarvoor de elementen van TMap HD toepassen en zo een basis creëren om het testproces opnieuw in te richten.
Deze blog is hierop een vervolg en gaat over onze ‘Quest for Quality’ met behulp van de building blocks uit TMap HD en de handvatten uit TMap in Scrum. Hiermee geven we een toelichting op het uiteindelijk ingerichte testproces.
TMap HD Building Blocks
TMap HD is een kwaliteitgedreven testaanpak, die zich heel goed leent voor een Agile omgeving. Met behulp van de building blocks wordt een testproces opgebouwd dat is afgestemd op onze specifieke situatie. Wij hebben diverse building blocks gebruikt om onze waardes te vertalen naar een concrete aanpak.
Building Block 7: Test Strategy
Het project waar we aan werken heeft een harde deadline. Dit betekent dat we de tijd en middelen die we hebben, zo efficiënt mogelijk moeten benutten. Een goede teststrategie helpt ons om te bepalen hoe we de testinspanningen verdelen over de te testen aspecten. Hiervoor moet er een afweging gemaakt worden op basis van risico’s, tijd en gewenst resultaat.
Building Block 6: Product risk analysis
De ‘Product Risk and Benefit analysis’ (PRBA) helpt ons om inzicht te krijgen in de risico’s en prioriteiten. Door de verdeling van de testinspanningen te baseren op de PRBA, kunnen we de balans tussen tijd, risico’s en resultaat goed verantwoorden. De PRBA hebben we zo opgebouwd, dat iedereen invloed heeft op de verdeling van de testinspanningen. De product owner bepaalt de prioriteit van de user story (Benefit). Op basis van de technische complexiteit en in overleg met de ontwikkelaars wordt de faalkans bepaald en de schade wordt bepaald door het hele team.
Building Block 20: Reviewing requirements
De teststrategie heeft als doel om de belangrijkste fouten zo vroeg en goedkoop mogelijk te vinden. Dit sluit aan bij de eigenschap van een kwaliteitgedreven aanpak: “Test in alle fasen en begin zo vroeg mogelijk” (Building Block 17: Quality-driven characteristics). Dit geven wij invulling door de requirements, in de vorm van user stories en schermontwerpen, te toetsen. In deze user stories worden de acceptatiecriteria uitgewerkt, om zo de schermontwerpen te voorzien van context. Dit moet ervoor zorgen dat de afspraken met de product owner eenduidig en compleet gecommuniceerd worden aan de ontwikkelaars.
Building Block 16: Using test tools
Een andere eigenschap van een kwaliteitgedreven aanpak stelt dat tests zo veel mogelijk - waar nuttig - geautomatiseerd moeten worden. Om zo meer, beter en vaker te testen. Dit realiseren we door het automatiseren van de regressietest en het testontwerp. Hiervoor maken we gebruik van ‘Model Based Test Design’ (Building Block 14: Model-based testing).
Door de combinatie van deze building blocks worden de door ons opgestelde waardes geïntegreerd in het testproces. De activiteiten die hieruit voortkomen, worden ingepast in het scrum model, om vervolgens het testproces te integreren met het ontwikkelproces.
De TMap fases in het Scrum model
“Failing to plan is planning to fail.”– Mr. Mikkel
Het is van belang om een testproces te ontwerpen wat is afgestemd op de overige activiteiten in de sprint en in staat is om in te spelen op de veranderende omgeving van het project. Hiervoor hebben we gebruik gemaakt van onderstaande afbeelding, afkomstig uit het boek TMap NEXT in Scrum. In deze afbeelding zijn alle fasen uit TMap NEXT geïntegreerd in een weergave van het scrummodel.
Het proces vastleggen
Uiteindelijk geeft onderstaande afbeelding weer hoe het proces vorm heeft gekregen. Het op deze manier vastleggen sluit – aangezien we ons nog bevinden in de overgangsfase van waterval naar Agile - niet geheel aan bij het Agile gedachtegoed. Het is echter van groot belang om onze aanpak op deze manier inzichtelijk te maken voor alle betrokkenen. Wel gaan we op een Agile manier om met dit proces. We plannen de testactiviteiten per sprint en voeren steeds die activiteiten met de hoogste prioriteit uit. We hebben dit proces gepresenteerd aan de testmanager en het hoofd van het ontwikkelteam, met enthousiaste reacties als gevolg. Mede dankzij het principe ‘continuous improvement’, gebruiken we de komende weken onze ervaringen om het proces te optimaliseren.
Meer weten over een kwaliteitgedreven testaanpak?
Wil je meer weten over de kwaliteitgedreven testaanpak van Sogeti? Kijk dan op onze Testing-pagina of stel je vraag via onderstaand contact.
