In dit blog zal ik mijn visie geven over testen binnen Scrum. Regelmatig hoor ik dat organisaties vinden dat

• er geen testers nodig zijn in een Scrumteam.
• de developers ook moeten testen.
• het niet mogelijk is TMap of ISTQB toe te passen voor het testen binnen scrum.
• testers ook ontwikkel taken moeten kunnen uitvoeren

Ik zal op een aantal punten de parallel trekken met de watervalmethode om het verschil, maar ook de overeenkomst duidelijk te maken. En dat een deel van de activiteiten uit TMap of ISTQB wel degelijk gebruikt worden binnen scrum.

Een voordeel van scrum, vanuit test perspectief gezien, is dat testen daadwerkelijk start vanaf het begin. Dit in tegenstelling tot de watervalmethode waar systeem/acceptatietesten aparte fases binnen het ontwikkeltraject zijn. Dit zorgt er voor dat al vroeg in het traject eventuele onjuistheden kunnen worden geconstateerd en direct worden opgelost. Voor een ieder die de Wet van Boehm kent, weet dat dit uiteindelijk tijd en geld gaat besparen.

Een scrum team heeft als doel werkende, voor productie geschikte, software op te leveren aan het einde van iedere sprint. Om dat te realiseren zullen dus ook de testen moeten zijn uitgevoerd. En dat is inclusief de testen die anders tijdens systeem- of acceptatietest worden uitgevoerd. Soms wordt er gedacht dat er binnen een sprint een systeem- en acceptatietest moet worden “ingepland”, waar alle backlog items worden getest. Op dat moment maak je van een sprint een waterval aanpak. En dat is niet de bedoeling.

Sequentieel versus continu testen

Bij het ontwikkelen volgens de watervalmethode is een acceptatietest een testsoort waarin een (1) of meerdere testvormen zijn ondergebracht. En heeft als doel vast te stellen dat een applicatie voldoet aan de gestelde requirements. Een acceptatietest is dan een testproject waarin alle activiteiten worden georganiseerd en uitgevoerd om vast te stellen dat aan de requirements is voldaan. Deze wordt uitgevoerd na het afronden van de systeemtest.

Een Scrum team heeft als doel een voor productie geschikte applicatie op te leveren aan het einde van iedere sprint. Dit betekend dat er ook aangetoond moet worden dat de applicatie voldoet aan de gestelde requirements. Hoe, door wie en wanneer binnen een sprint testen worden uitgevoerd wordt door het Scrum team bepaald. Zo kan het functioneel testen van een requirement al worden uitgevoerd zodra de code is ontwikkeld en er een unit test is uitgevoerd. De resultaten kunnen daarna al worden besproken met de product owner, die uiteindelijk het product van een sprint moet accepteren. Binnen een sprint is er dus geen afgebakende periode waarin “de acceptatietesten” worden uitgevoerd. Testen is geen sequentiële activiteit die aan het einde van een sprint wordt uitgevoerd, maar een continue activiteit die wordt uitgevoerd op het moment dat dat het meest efficiënt is.

Testinspanning en teststrategie

Ook binnen Scrum zal ongeveer 30% van het werk betrekking hebben op testen. En dat zijn alle noodzakelijke testactiviteiten. Wat, hoe en met welke diepgang er getest moet worden is uiteraard afhankelijk van de risico’s. Er zal dan ook per backlog item een product risico analyse moeten worden uitgevoerd. Wanneer er ter voorbereiding op een sprint een refinement is, dan is dat het moment om de PRA te doen. De product owner licht de backlog items toe en deze worden eventueel met informatie aangevuld. Op dat moment kunnen ook de mogelijke risico’s worden besproken per backlog item. Het voordeel om tijdens de refinement al de PRA te doen, is dat er voor de sprintplanning al nagedacht kan worden over de noodzakelijke testinspanning. Lees teststrategie. En dit is weer waardevolle achtergrondinformatie voor het toekennen van de story points tijdens de sprint planning. Is er geen refinement dan zal de PRA tijdens de sprint planning moeten worden gedaan.

Toepassen testontwerptechnieken

De teststrategie is ook binnen scrum de basis voor het bepalen van de wijze waarop de testen worden voorbereid en uitgevoerd. Het teamlid die de test uitvoert voor een backlog item bepaalt op basis van de teststrategie de testgevallen en voert deze uit. Hiervoor kunnen gangbare testontwerptechnieken worden gebruikt, die ook bij een watervalmethode worden gebruikt. Je kunt er wel voor kiezen om de verschillende stappen van een testontwerptechniek niet volledig uit te werken. Alleen de testgevallen zelf worden geregistreerd en niet de stappen om tot een testgeval te komen. Het registreren van de testgevallen en deze koppelen aan het backlog item is wel belangrijk. Ze kunnen gebruikt worden voor regressietesten en geven de product owner informatie voor de accepta

Testexpertise binnen scrum team

Binnen een Scrum team bestaat alleen de rol van developer. Er zijn mensen die dit interpreteren als, “er zitten alleen ontwikkelaars in een team en geen testers. De ontwikkelaars doen ook het testen.” Deze interpretatie impliceert dat het altijd mogelijk is om een team samen te stellen met ontwikkelaars die beschikken over de gewenste expertise en ervaring op het gebied van programmeren, database, infrastructuur, technische en functionele testen, etc. En dat ze ook in staat zijn een architectuur te ontwerpen en specificaties te maken. Dus allemaal schapen met niet 5 maar 8 poten. Een Scrum team is een multifunctioneel team, waar teamleden in zitten die gezamenlijk over de juiste expertise en vaardigheden beschikken om het gewenste resultaat te realiseren.

Een of meer teamleden met testexpertise op het gebied van PRA, teststrategie, testontwerptechnieken, geautomatiseerd testen, testtooling, etc. zijn toch al snel mensen met een gedegen testachtergrond. In de praktijk zie je dan ook vaak dat in een team 1 op de 3 teamleden een test achtergrond heeft. Dit wil niet zeggen dat zij alle testwerkzaamheden doen of alleen maar testen. Zij brengen hun testexpertise in om ervoor te zorgen dat het team het gewenste resultaat gaat realiseren.

Impact van scrum voor testers

Wanneer je als tester werkt in een waterval georganiseerd project, dan zal er een testplan zijn opgesteld door een testmanager of testcoördinator met daarin de PRA, teststrategie en te gebruiken testontwerptechnieken. Je belangrijkste taak is dan het opstellen en uitvoeren van testgevallen. Het eventueel automatiseren van de testgevallen kan ook een taak zijn van de tester.Werk je als tester in een scrum team dan is er geen testplan. Je zult als tester de expertise moeten hebben om een PRA uit te voeren en een teststrategie op te stellen. Het voordeel van scrum is dat je deze activiteiten uitvoert tijdens de refinement en/of sprintplanning per backlog item. Waarbij ook nog eens de product owner aanwezig is voor de belangrijkste input.

Er wordt veel gesproken en geschreven over de technische kennis die testers moeten hebben om in een scrum team te kunnen werken. Dat wordt dan vaak weer geïnterpreteerd als “testers moeten ook kunnen programmeren”. Ik zelf vind dat te ver gaan. Wel is het hebben van basiskennis over bijvoorbeeld programmeren, SQL of XML belangrijk. Niet om te programmeren, maar om ontwikkelaars beter te begrijpen en vragen te kunnen stellen om een efficiëntere teststrategie te kunnen opstellen.