05 nov 2026 Agile testen: wat doet een tester in een Scrum-team, sprint na sprint?

In het kort: Agile testen betekent dat testen bij elke sprint hoort, niet bij een fase aan het eind. Het hele team is verantwoordelijk voor kwaliteit, en de tester brengt testontwerp en risicodenken in. Een tester helpt stories scherp te krijgen voor de sprint, test werk zodra het af is en zorgt dat de regressieset bijblijft. Zonder automatisering houdt dat ritme het maar een paar maanden vol.

Veel teams werken in sprints, maar testen zoals ze dat vroeger deden. Developers bouwen acht dagen, en testen krijgt de laatste twee. Elke sprint eindigt met haast, en wat niet getest is, schuift door naar de volgende. Op papier is het team agile. In de praktijk zit er in elke sprint een kleine waterval. Agile testen is de weg daaruit, en het begint bij de rol van de tester.

Wat is agile testen?

Agile testen is testen dat door de hele sprint heen gebeurt, door het hele team. Zo is elk stuk werk echt af als de sprint eindigt. Het volgt uit hoe Scrum “af” definieert. Volgens de Scrum Guide telt werk pas als increment als het voldoet aan de definition of done van het team, de afgesproken lijst met kwaliteitseisen. Staat testen niet op die lijst, dan betekent “af” alleen “gebouwd”. Bij agile testen wacht een tester niet aan het eind van de lijn. Hij werkt mee met developers en de product owner, vanaf het eerste gesprek over een story. Developers schrijven unittests voor hun eigen code. De product owner weet wat de business nodig heeft. De tester brengt in waar de anderen vaak geen tijd of opleiding voor hebben. Dat is bedenken waar het kan breken, risico’s inschatten en controleren of het geheel samenwerkt. Kwaliteit is van het team. Testontwerp en risicodenken zijn het vak van de tester.

Dat idee gaat terug op het Agile Manifesto: werkende software is de maat voor voortgang. En ongeteste software werkt nog niet aantoonbaar.

Wat doet een tester tijdens een sprint?

Het werk van een tester is verdeeld over de hele sprint, niet bewaard voor het eind. Elk moment in de sprint heeft een eigen taak. Voordat het werk begint, helpt de tester stories testbaar te maken. Tijdens de sprint test hij elke story zodra die klaar is, en automatiseert hij wat moet blijven werken. Aan het eind helpt hij het team bepalen of het werk echt af is. Deze tabel laat het gebruikelijke ritme zien.

Niet elke tester doet dit allemaal alleen. In een team met sterke developers ligt veel van de testautomatisering soms bij hen. De tester bewaakt dan het testontwerp en het totaalbeeld.

Waar gaat testen in een sprint meestal mis?

Het gaat op drie voorspelbare manieren mis, en vaak tegelijk. Geen daarvan komt door luie mensen. Ze komen voort uit hoe het werk gepland is. Herken je er een, dan zit de oplossing meestal in de planning, niet in harder werken. Dit zijn de drie.

• Een kleine waterval in de sprint. Stories zijn laat af, dus al het testen valt in de laatste dagen. Wat niet past, schuift door naar de volgende sprint.
• Eén tester voor meerdere teams. De tester rent van de ene stand-up naar de andere, en refinement schiet er als eerste bij in.
• Regressie die het niet bijhoudt. Elke sprint voegt functies toe die je de volgende keer opnieuw moet controleren. Met de hand groeit die regressieronde tot hij de sprint opeet.

Die derde overvalt ook teams die wel automatisering hebben. In gesprekken horen we vaak hetzelfde verhaal. De dekking blijft een paar maanden na de start steken, omdat het repareren van oude tests de tijd voor nieuwe opslokt. Een kapotte test wordt “even” overgeslagen, en niemand komt er nog op terug. Een jaar later weet niemand of het dekkingspercentage nog te vertrouwen is. Voelt testen als de rem op je team? Ons stuk over waarom QA de bottleneck lijkt kijkt naar de doorstroom van werk eromheen.

Hoe houdt testautomatisering het sprintritme overeind?

Met automatisering kun je elke sprint alles opnieuw testen zonder dat het werk elke keer groeit. De regel is eenvoudig. Als een story af is, gaan de controles die hem bewaken in de geautomatiseerde regressieset, in dezelfde sprint of de volgende. Daarna draaien die controles elke nacht vanzelf. De tijd van de tester gaat dan naar nieuw werk, onderzoeken en overleg met het team. Niet naar het met de hand herhalen van de controles van vorige maand. In onze uitleg over de regressietest lees je wat je het eerst automatiseert.

Onze case Financial Institution laat zien hoe dat binnen een Scrum-team werkt. Onze consultant professionaliseerde het geautomatiseerde functionele testen van nieuwe front-end applicaties voor de verkoop van verzekeringen. Fitnesse ondersteunde de acceptatietests en de samenwerking tussen business en development. Selenium, Protractor en SoapUI dekten de browser, de front-end en de API’s af. Voor de kritieke functies kwamen geautomatiseerde tests, zodat het team ze elke iteratie kon blijven testen.

Twee kanttekeningen horen erbij. Niet elk team heeft een fulltime tester nodig. Een klein team met developers die goed testen, kan soms met een paar dagen per week toe, als iemand het testontwerp bewaakt. En automatisering dekt nooit alles. Exploratief testen vindt wat geen script controleert, en acceptatietesten door gebruikers uit de business bepalen of het werk past bij hoe zij echt werken. Beide blijven mensenwerk.

Wat betekent dit voor je team?

Kijk naar je laatste drie sprints. Wanneer begon het testen van elke story, en hoeveel van de regressie ging nog met de hand? Valt testen steeds in de laatste dagen, dan zit het probleem in het ritme, niet in de mensen. Maak testen onderdeel van je definition of done. Haal een tester bij de refinement. En plan het automatiseren van afgerond werk in als deel van elke story.

Dat werkt het best met een tester die weet hoe je dit binnen een team aanpakt. Via QA & Testen schuiven onze testconsultants aan bij je team, van teststrategie tot het testwerk zelf, in je eigen tools en sprints. Peter van Lint van Technolution schreef op onze homepage dat onze testers heel goed opgaan in hun projecten. Met hun advies en inzet tillen ze het geautomatiseerde en handmatige testen naar een hoger niveau. Is de groeiende regressieset het grotere probleem? Dan draait en onderhoudt Test Automation as a Service die samen met je team.

Een eerste stap voor deze week: zet één regel bij je definition of done. Bijvoorbeeld: “de controles voor deze story staan in de geautomatiseerde regressieset”.

Veelgestelde vragen

Heeft een Scrum-team een eigen tester nodig?

Niet altijd. De Scrum Guide noemt geen aparte rol voor een tester; het team als geheel levert een af increment. Maar iemand heeft de kennis en de tijd nodig voor testontwerp en risicodenken. In veel teams lukt dat het best met een tester.

Wie is verantwoordelijk voor kwaliteit in een Scrum-team?

Het hele team. Developers testen hun eigen code en de product owner kijkt of het doet wat nodig is. De tester brengt testontwerp, risicoanalyse en het totaalbeeld in. De definition of done maakt dat concreet.

Hoeveel testers heb je per team nodig?

Daar is geen vast getal voor. Het hangt af van hoeveel er per sprint verandert, hoe riskant dat is en hoeveel regressie geautomatiseerd is. Teams met goede automatisering hebben minder mensen nodig voor herhaalwerk, en meer tijd om te onderzoeken.

Test je in dezelfde sprint als waarin gebouwd wordt?

Ja, zoveel mogelijk. Een story is pas af als hij getest is. Test je een sprint later, dan komen bugs terug als developers alweer met iets anders bezig zijn, en dan kost repareren meer.