De rol van de tester in een Scrum team

Scrum is een veel toegepaste werkwijze bij de ontwikkeling van software. Deze Agile aanpak heeft een hoop voordelen, maar er zijn ook – zoals in elk model – een aantal uitdagingen.

Zo zijn de eisen aan het testen binnen scrum in de afgelopen jaren enorm veranderd. Het is lang niet meer voldoende om na ontwikkeling van een stuk code (achteraf) bugs te rapporteren. Binnen de cycli van scrum wordt het steeds belangrijker problemen te voorkomen, door bijvoorbeeld een diepgaander beeld te krijgen van de kwaliteit van de software.

Ben je benieuwd hoe je de rol van tester in een Scrum team kunt bekleden? In deze blog vertellen we je de uitdagingen en manieren om als tester in een Scrum team te fungeren.

Binnen de agile aanpak Scrum kennen we drie rollen: de product owner, de scrum master en het Scrum team. Er ‘bestaat’ dus geen officiële rol als tester. In theorie is dit namelijk de verantwoordelijkheid van het gehele Scrum team. Hoe verloopt het testen in deze teams? In veel bedrijven worden alsnog testexperts ingehuurd of trekt men QA engineers aan om testen in de juiste banen te leiden.

Er is veel verschil in de implementatie van Scrum, wat elk zijn eigen uitdagingen met zich mee brengt. De implementaties staan hier onder beschreven:

In de praktijk zien wij veel verschillen in de toepassing van het scrumprincipe. Één daarvan is het beste als “waterval met sprints” te omschrijven.

Hierbij wordt voornamelijk het cyclische element uit agile scrum overgenomen, maar niet de scrum mindset. Binnen een sprint wordt nog steeds een fasering toegepast met aan het einde een mini testfase. De user story dient volledig te zijn omschreven, ontworpen, aangevuld met uitzonderingen en volledig gebouwd te zijn voordat er aan testen kan worden gedacht. Het resultaat van zo’n opzet is vaak dat aan het einde van een sprint onvoldoende tijd voor de testuitvoer blijft. Het project heeft dan nog maar twee mogelijkheden om hierop te reageren:

1. De niet afgeronde user stories worden opgeschoven naar de volgende sprint, waardoor de voortgang hiervan vertraging oploopt. 

2. De release wordt onvolledig getest gecontinueerd. 

Een andere situatie is dat men het Scrum principe goed naleeft. Zo verloopt bijvoorbeeld de ontwikkeling van een user story stapsgewijs en is elk aspect (analyse, ontwerp, realisatie en test) hierin meegenomen.

De testers zijn in elke fase meegenomen, waarbij testen alvorens op basis van requirements zijn opgesteld. De testen zijn al voorbereid en eventueel mogelijke problemen zijn tijdens de ontwerpfase onderschept.

Dit heeft als groot bijkomend voordeel dat de kosten van bevindingen drastisch verminderen. Hoe eerder deze worden gevonden in het proces, des te eerder men ze kan oplossen. Dit principe is duidelijk gemaakt in de wet van Boehm.

Daarnaast is het team flexibeler om feedback direct te verwerken in de eerstvolgende sprint. Hierdoor kan de tester vooruit werken en de acceptatiecriteria actief najagen.

Ook in het Scrum framework komen situaties voor waarbij testen als noodzakelijk kwaad gezien wordt en daardoor niet altijd optimaal wordt benut. Vaak is de ontwikkeling van (automatische) testen niet meegenomen in de scope van de sprint, waardoor hier onvoldoende rekening mee wordt gehouden. Ook het bepalen van de dekking van de testen wordt vaak overgeslagen, net als het ontwikkelen en uitvoeren van unit tests. De betrokkenheid van de business – dan spreken we meestal over de product owner – is vaak een uitdaging. Als deze de producten en bijbehorende testen pas aan het einde bij de demo te zien krijgt, kan dit tot misverstanden leiden. Dan is er nog het vraagstuk van documentatie: moet we dit nog creëren? En in welke mate? Wat geven we weer? Het documenteren gebeurt niet altijd of na een aantal sprints, waarbij de insteek vertroebelt en de inhoud onduidelijkheden bevat. Dit geldt voor zowel ontwikkeling als testactiviteiten.

Het gebruik van user stories wordt vaak gecombineerd met de Agile-software-ontwikkelingstechniek Behavior Driven Development (BDD). Op deze manier is altijd een ontwikkelaar, tester en een eindgebruiker aanwezig in het proces. Hierdoor kunnen misverstanden over de requirements voorkomen worden, kan de user story gunstig beperkt worden tot de kern en begint de feedbackloop al voor de ontwikkeling. Het geeft de tester en ontwikkelaar namelijk gelijk de kans relevante vragen te stellen en verwachtingen te managen. Hierdoor kan het aantal user stories beperkt worden en op technisch gebied gekeken worden naar de meest efficiënte manier van ontwikkelen. Op deze manier kan veel tijd gewonnen worden. In dit systeem fungeert de tester vaak als brug tussen technische beschrijvingen van de ontwikkelaar en de zakelijke beschrijving van de gebruiker.

De verandering in de rol van de tester, onder andere door het inzetten van BDD, is een gevolg van het Testing Manifesto. Hierin wordt benadrukt dat het belang van testen verder gaat dan het vinden van bevindingen. Dit maakt het belangrijk voor testers om te weten wat gebruikers en de business echt van het product verwachten. Testers dragen zo bij aan het doel het best mogelijke systeem te ontwikkelen dat aansluit bij de verwachtingen van de gebruikers. Deze verandering wordt ondersteund doordat automatische testen steeds meer de repeterende activiteiten van testers overnemen, waardoor zij hun handen vrij hebben om deze nieuwe rol optimaal in te vullen.

Door op deze manier te werken worden veel kosten en tijd bespaard en komen testers vrijwel nooit meer in tijdnood. Daarnaast zijn de gevonden bevindingen direct van toepassing op de verwachtingen van de eindgebruikers en zullen deze vrijwel altijd door de rest van het team geaccepteerd worden.

Uiteindelijk is het van groot belang dat de rolverdeling voor iedereen in het Scrum team duidelijk is en dat men een ideale werkwijze in het achterhoofd houdt die gezamenlijk is opgesteld en daar actief naar blijft streven. Op deze manier is het testen van software iets waar men op vertrouwt: samen streven we naar het optimaal voldoen aan de verwachtingen van de (eind)gebruiker. Hoe zijn de rollen in jouw Scrum team verdeeld?