09 nov 2026 Kosten testautomatisering: wanneer verdien je het terug?

In het kort: De kosten testautomatisering zitten maar voor een klein deel in de bouw. Het grootste deel is onderhoud: tests bijwerken na elke wijziging, release na release. Testautomatisering verdient zich terug als je testset jarenlang blijft draaien en je team de uitkomst vertrouwt. Valt het onderhoud weg, dan betaal je de bouw vaak twee keer.

Testautomatisering die na een jaar stilvalt, levert niets op. Het is een dure pauze voordat je opnieuw begint. We zien het vaak: een team bouwt een testset, die werkt een paar maanden goed, en dan verliest het onderhoud het van nieuwe features. Kijk je naar de kosten testautomatisering, vraag dan dus niet alleen wat de bouw kost. Vraag wat het kost om de tests draaiend te houden, en wat je daarvoor terugkrijgt.

Wat levert testautomatisering op, en wat kost het?

Testautomatisering levert tijd op die je team nu kwijt is aan handmatig testen, plus dingen die pas kunnen als tests vanzelf draaien. Denk aan snelle feedback voor ontwikkelaars en releases die niet een week wachten op een testronde. Daartegenover staan de bouw, de tools, de mensen en het onderhoud. In het Engels heet die afweging test automation ROI, de return on investment. Het belangrijkste woord is tijd. Een testset kost het meest in de eerste maanden en verdient zich langzaam terug, release na release. Reken je over zes maanden, dan valt het bijna altijd tegen. Over drie jaar kan het heel goed uitpakken, maar alleen als de set in jaar drie nog draait. Daarom telt onderhoud zwaarder dan elk ander getal. Een regressietest, de test die controleert of wat gisteren werkte vandaag nog werkt, draait elke release opnieuw. Bij elke run verdien je iets terug.

Hoe maak je een eerlijke schatting?

Begin bij wat handmatig regressietesten je nu kost. Tel de uren per release en vermenigvuldig die met het aantal releases per jaar. Dat zijn de jaarlijkse kosten die je deels kunt terugwinnen. Schat daarna de andere kant: de bouw, één keer, en het onderhoud, elk jaar. Wees eerlijk over dat tweede getal. Dat schatten de meeste teams te laag.

Een verzonnen voorbeeld met ronde getallen, alleen om de som te laten zien. Je team besteedt 60 uur per release aan handmatige regressietests en je brengt 12 releases per jaar uit. Dat is 720 uur per jaar. Stel dat automatisering het meeste daarvan voor zijn rekening neemt en dat de bouw 400 uur kost. Kost onderhoud daarna 200 uur per jaar, dan heb je de bouw in het eerste jaar terugverdiend. Kost onderhoud 600 uur per jaar, dan speel je net quitte. Zelfde tool, zelfde tests, heel andere uitkomst. Reken met je eigen getallen, en neem deze kosten mee.

Welke kosten vergeten de meeste sommen?

Je vergeet vooral de kosten die langzaam groeien. Onderhoud is de grootste. Elke release verandert schermen, regels en data, en elke wijziging kan een test breken. We zien de dekking een paar maanden na de start vaak stilvallen. Oude tests repareren kost de tijd die bedoeld was voor nieuwe. Een kapotte test wordt “even” overgeslagen, en niemand komt er nog op terug.

Drie andere kosten staan bijna nooit in de som.

• Eén persoon. Heeft één engineer de set gebouwd en snapt alleen die hem, dan betaal je voor een risico. Vertrekt die persoon, dan stopt de set vaak ook.
• Verloren vertrouwen. Tests die zonder echte reden falen, flaky tests, leren mensen rode uitslagen te negeren. Dan kost de set geld en beschermt hij niets.
• Opnieuw beginnen. Een set die stilvalt, wordt opnieuw gebouwd, soms meer dan eens. Elke herstart betaal je de bouw opnieuw.

Het duurste misverstand dat we horen: zelf doen is goedkoper. Op papier klopt dat. In de praktijk ben je maanden bezig een schaars profiel te werven, in te werken en een eigen framework te bouwen. Daarna groeit het onderhoud met elke release, en heb je minstens twee mensen nodig zodat het niet aan één persoon hangt.

Welke opbrengsten vergeten de meeste sommen?

De grootste opbrengsten zijn snelheid, rust en betere inzet van je mensen, en die zie je zelden terug als uren. Een testset die elke nacht draait, vertelt ontwikkelaars de volgende ochtend wat er stuk is, terwijl de wijziging nog vers in hun hoofd zit. Dan is het snel opgelost. Dezelfde bug drie weken later in een testronde vinden is traag en duur. Onderzoek van DORA naar testautomatisering koppelt betrouwbare geautomatiseerde tests aan sneller opleveren én stabielere releases.

Ook looptijd is winst. In onze Data Warehouse-case ging het uitvoeren van de geautomatiseerde tests van dagen naar minder dan 30 minuten, met stabiele resultaten. Een testset die in een half uur draait, kan voor elke release mee. Een set die dagen duurt, sla je over als de tijd krap is.

En dan de tijd van je testers. Draaien de herhalende checks vanzelf, dan houden testers tijd over voor werk dat geen script kan doen. Exploratief testen vindt wat niemand had bedacht. Acceptatietesten door je gebruikers laat zien of een wijziging echt past bij hoe zij werken. Automatisering vervangt geen van beide. Het maakt er ruimte voor.

Wanneer loont testautomatisering niet?

Testautomatisering loont niet als de tests te weinig draaien om hun kosten terug te verdienen. Dat geldt voor software die bijna niet verandert, of voor een project dat over een paar maanden stopt. Het loont ook nog niet als schermen elke week veranderen. Dan herschrijf je de tests sneller dan ze tijd opleveren. Begin in die fase bij de stabiele lagen eronder, zoals bedrijfsregels die je via de API test, de laag waarlangs systemen gegevens uitwisselen. De testpiramide van Martin Fowler legt uit waarom tests op een lagere laag goedkoper zijn in onderhoud.

We zouden ook niemand aanraden om alles te automatiseren. Elke test die je toevoegt, moet je voor altijd onderhouden. Een kleine set die je belangrijkste bedrijfsprocessen bewaakt, verdient zich sneller terug dan een grote set die niemand vertrouwt.

Wat betekent dit voor je team?

De som klopt pas als iemand de testset draaiend houdt, release na release. Juist dat werk blijft in de meeste teams liggen. Het is geen feature, het komt niet langs in een sprintdemo en het belandt bij wie toevallig tijd heeft. En vlak voor een release heeft niemand tijd.

Dat onderhoud pakken we op met Test Automation as a Service, samen met je team. Voor teams die hun regressietests nog met de hand doen, halen we tot 70% van het handmatige regressietesten weg. Je tests draaien elke nacht, en wij houden ze betrouwbaar. Je krijgt een stabiele testset waar je team op kan vertrouwen, die niet van één persoon afhangt en je team geen extra werk geeft. We bouwen, documenteren en onderhouden de set, zodat hij van jou blijft. Je team houdt de regie over wat er live gaat.

Een eerste stap voor deze week: tel de uren die je team kwijt was aan handmatige regressietests in de laatste drie releases. Dat is het getal dat je automatisering elk jaar moet verslaan.

Veelgestelde vragen

Wanneer verdient testautomatisering zich terug?

Dat hangt af van hoe vaak je releaset en hoeveel je nu met de hand test. Teams die vaak releasen en veel handmatig testen, verdienen het sneller terug. Met een paar releases per jaar duurt het langer.

Is testautomatisering de moeite waard voor een klein team?

Vaak wel, als je software regelmatig verandert. Begin klein, bij de processen die echt niet mogen breken. Een klein team voelt het onderhoud sterker, dus spreek vooraf af wie de tests draaiend houdt.

Wat zijn de verborgen kosten van testautomatisering?

Onderhoud na elke wijziging, testdata, een tweede persoon als back-up en tests die zonder echte reden falen. De grootste verborgen kostenpost is een set die stilvalt en opnieuw gebouwd moet worden.

Vervangt testautomatisering handmatige testers?

Nee. Het doet de herhalende checks. Mensen blijven exploratief testen, bepalen wat belangrijk is en begeleiden acceptatietesten. In ons artikel over regressietesten zie je hoe die twee samenwerken.