15 okt 2026 “QA is de bottleneck”: waarom extra testers je releases niet sneller maken, en wat shift left testing doet

In het kort: Wordt QA de bottleneck genoemd, dan zit de oorzaak meestal in het hele ontwikkel- en opleverproces. Extra testers geven je meer capaciteit, maar nauwelijks snellere releases, omdat handmatige regressie met elke release groeit en testers wachten op opleveringen. Shift left testing helpt: eerder testen, de regressie die steeds terugkomt automatiseren en die bij elke wijziging draaien.

“Het testen houdt ons tegen.” De meeste teamleads hebben die zin weleens gehoord in een planningsoverleg. De release is klaar, op het testen na. Het voor de hand liggende antwoord is testers erbij zetten. Een paar maanden later is het team groter, zijn de kosten hoger en gaan de releases nauwelijks sneller. Dat is frustrerend voor iedereen, ook voor de testers, want die werkten al die tijd hard.

Waarom lijkt QA de bottleneck?

QA lijkt de bottleneck omdat testen de laatste stap is voor een release, dus elke vertraging eerder in het proces komt daar terecht. Werk komt laat binnen, in grote brokken, soms van meerdere leveranciers tegelijk. Testers hebben dan dagen nodig om nieuwe functies te controleren en de regressietests met de hand te herhalen. Ondertussen schuift de deadline niet op. Van buitenaf lijkt het alsof testen traag is. In onze ervaring zit de oorzaak meestal in het hele ontwikkel- en opleverproces. We vergelijken het vaak met de A4 verbreden zonder de verkeersstromen eromheen aan te pakken. Je voegt capaciteit toe, maar er komt nauwelijks meer verkeer door.

Waarom maken extra testers je releases niet sneller?

Extra testers maken je releases niet sneller, omdat de meeste extra tijd opgaat aan werk dat steeds groeit. Drie dingen blijven gelijk, hoeveel testers je ook toevoegt:

• Handmatige regressie groeit met elke release. Elke nieuwe functie voegt controles toe die je de volgende keer moet herhalen. De regressieronde wordt langer, niet korter.
• Testers wachten op opleveringen. Komt werk pas aan het eind van een sprint binnen, of levert elke leverancier apart op, dan wachten extra testers vooral samen.
• Omgevingen en data zijn niet klaar. Verandert de testdata onder de tests, of verschillen de omgevingen, dan gaat een deel van elke testdag op aan klaarzetten.

Bij teams die met meerdere leveranciers werken, zien we nog een effect. Business en QA zijn zo lang bezig met het controleren van losse opleveringen dat sprintdoelen schuiven. En leveranciers erbij halen wordt lastiger, omdat je eigen proces niet meegroeit.

Wat is shift left testing in de praktijk?

Shift left testing betekent dat je eerder in het proces begint met testen, in plaats van het tot het eind te bewaren. De naam komt van een tijdlijn die van links naar rechts loopt: testen schuift naar links, dichter naar het begin. Het Software Engineering Institute van Carnegie Mellon beschrijft er meerdere vormen van, van meer unit- en integratietests tot doorlopend testen in korte sprints. Voor een team dat vastzit, komt het neer op een handvol gewoontes:

1. Testers schuiven aan bij de refinement. Ze vragen “hoe gaan we dit testen?” voordat iemand het bouwt. Zo komen onduidelijke eisen vroeg boven.
2. Acceptatiecriteria die je kunt testen. Elke story beschrijft met voorbeelden wanneer iets af is.
3. Bedrijfsregels getest via de API. Regels en berekeningen controleer je waar systemen met elkaar praten, en dat is snel en stabiel. Daarover schreven we in API testen: bewaak je businesslogica.
4. Automatische regressie bij elke wijziging. De controles die elke release terugkomen, draaien vanzelf in de pipeline, elke nacht of bij elke merge.
5. Testdata die je kunt herhalen. Tests nemen hun eigen data mee, zodat ze niet falen omdat iemand een record heeft aangepast.

Wat automatiseer je eerst om releases los te trekken?

Automatiseer eerst de regressietests die je elke release herhaalt en die je grootste risico’s dekken. Dat is het werk dat het snelst groeit en releases het meest ophoudt. Begin klein: de bedrijfsprocessen die nooit mogen breken, de berekeningen die geld kosten als ze fout gaan, en de koppelingen met andere systemen. Een compacte regressietest die elke nacht draait, doet meer voor je releasetempo dan een grote set die niemand vertrouwt. Houd exploratief testen en acceptatietesten bij mensen. Daar voegen testers het meest toe, en ze krijgen er tijd voor zodra het herhaalwerk vanzelf draait.

Wat betekent dit voor je team?

Voelt QA als je bottleneck, kijk dan eerst naar de doorstroom en pas daarna naar het aantal mensen. Waar wacht werk? Wat doe je elke release opnieuw met de hand? Welke tests falen om redenen die niemand vertrouwt? De antwoorden wijzen meestal naar een paar aanpassingen in het proces en een regressieset die vanzelf draait.

Het addertje: een geautomatiseerde regressieset heeft iemand nodig die hem draaiend houdt. Elke nacht, na elke wijziging, met iemand die oplost wat breekt. Dat werk schuift snel naar achteren als het team druk is met de volgende release, en dan wordt de testset langzaam niet meer vertrouwd. Dit is het deel dat wij oppakken met Test Automation as a Service. In de eerste dagen bekijken we samen met je team hoe er nu getest wordt en waar de knelpunten zitten. In de eerste week spreken we doelen en prioriteiten af, en binnen de eerste maand staat er een werkend proof of concept. Daarna houden we de regressieset draaiend, samen met je team, zodat je testers tijd hebben voor het werk dat hen nodig heeft. Lees hoe het werkt op onze pagina over Test Automation as a Service.

Veelgestelde vragen

Wat betekent shift left bij QA?

Dat testen eerder begint. Testers denken mee over de eisen, en bedrijfsregels worden getest zodra ze gebouwd zijn. Regressietests draaien automatisch bij elke wijziging, in plaats van in een lange ronde voor de release.

Is QA een bottleneck in agile teams?

Het lijkt vaak zo, omdat testen de laatste stap is voor een release. De echte oorzaak is meestal werk dat laat binnenkomt, regressie die met de hand gaat, en omgevingen of data die niet klaar zijn.

Vervangt testautomatisering de tester?

Nee. Automatisering neemt de controles over die elke release terugkomen. Testers blijven nodig om te bepalen wat je test, voor exploratief testen en voor acceptatietesten met gebruikers uit de business.

Hoe snel worden releases sneller?

Dat hangt af van waar je begint. Een kleine, betrouwbare regressieset voor je grootste risico’s kan binnen een paar maanden verschil maken. Elke controle die je automatiseert, bespaart daarna bij elke release weer tijd.