"Automatiseer zoveel mogelijk." Dat klinkt logisch. Maar het is geen strategie. Sommige tests verdienen zichzelf terug binnen drie maanden. Andere kosten meer dan ze ooit opleveren. Het verschil zit niet in het type test, maar in een berekening die de meeste teams nooit maken.
Veel teams beslissen op gevoel. Een test voelt belangrijk, dus wordt hij geautomatiseerd. Of een test voelt te ingewikkeld, dus blijft hij manueel. Het resultaat: suites vol tests die zelden draaien, en handmatige regressies die elke sprint tijd kosten.
Er bestaat een eenvoudig model dat die discussie beslecht. Het dwingt je om de juiste vraag te stellen: hoe lang duurt het voor deze test zichzelf terugbetaalt?
De formule
Meer is het niet. En toch vullen de meeste teams dit nooit in. Laten we het concreet maken.
Een uitgewerkt voorbeeld: de payment flow
Stel: je wil de payment flow van je webshop automatiseren. Een kritiek pad, dat elke sprint manueel wordt nagelopen. Dit zijn de cijfers:
Reken je dat uit over het eerste jaar, dan krijg je dit:
De test betaalt zichzelf terug, en ruim. Maar interessanter dan de jaarwinst is het moment waarop het omslaat:
Vanaf sprint zeven lever je winst op. Elke sprint bespaar je 45 minuten manueel werk. Trek daar 10 minuten onderhoud van af en je houdt 35 minuten netto per sprint over. Dat loopt op.
De berekening hierboven kijkt alleen naar uitgespaarde testtijd. De echte businesswaarde kan nog hoger liggen door snellere feedback en minder releaserisico.
Wanneer automatiseren níet loont
Hier wordt het interessant. Diezelfde formule laat namelijk ook zien wanneer je beter niet automatiseert. Draai aan de knoppen en de business case klapt om.
De feature verandert elke paar weken
Onderhoud vreet de winst op. De test is verouderd nog voor hij rendeert.
De test wordt zelden uitgevoerd
Break-even duurt jaren. Manueel testen blijft simpelweg goedkoper.
De UI is instabiel
De test breekt sneller dan je hem kan bijhouden. Je onderhoudt een suite in plaats van software te leveren.
De vuistregel
Als je maar één ding meeneemt uit dit artikel, laat het dit zijn:
Dat is geen dogma, maar een filter. Voldoet een test aan alle drie, dan is de business case bijna altijd positief. Ontbreekt er één, reken het dan uit voor je begint. En ontbreken er twee, dan weet je genoeg.
Met test automation koopt je team tijd terug. Geen eindeloze manuele regressies die elke sprint langer duren, maar ruimte om te bouwen aan wat écht waarde toevoegt, of om grondiger te zijn waar het telt. Dat is de winst. De formule helpt je alleen om te bepalen wáár je die winst haalt.
Vul je eigen ontwikkeltijd, onderhoud en manuele testtijd in en zie meteen waar je break-evenpunt ligt.
Dit artikel verscheen eerder als carrousel op LinkedIn, met de formule, het rekenvoorbeeld en de vuistregel in zes slides.
Bekijk op LinkedInBenieuwd wat dit voor jouw suite betekent?
We nemen je testset door en rekenen samen uit wat automatiseren oplevert. En wat je beter manueel houdt.
Plan een gesprek