"Automate as much as possible." That sounds logical. But it isn't a strategy. Some tests pay for themselves within three months. Others cost more than they will ever save. The difference isn't the type of test, it's a calculation most teams never make.
Many teams decide on gut feeling. A test feels important, so it gets automated. Or a test feels too complicated, so it stays manual. The result: suites full of tests that rarely run, and manual regressions that cost time every sprint.
There's a simple model that settles the discussion. It forces you to ask the right question: how long before this test pays for itself?
The formula
That's really all there is to it. And yet most teams never fill it in. Let's make it concrete.
A worked example: the payment flow
Say you want to automate the payment flow of your webshop. A critical path, checked manually every sprint. Here are the numbers:
Work that out over the first year, and you get this:
The test pays for itself, comfortably. But more interesting than the annual gain is the moment it tips over:
From sprint seven onward you're in profit. Every sprint you save 45 minutes of manual work. Subtract 10 minutes of maintenance and you keep 35 net minutes per sprint. That adds up.
The calculation above only looks at saved testing time. The real business value can be even higher thanks to faster feedback and less release risk.
When automating doesn't pay off
This is where it gets interesting. The same formula also shows when you're better off not automating. Turn the dials and the business case flips.
The feature changes every few weeks
Maintenance eats the gain. The test is outdated before it ever pays off.
The test rarely runs
Break-even takes years. Manual testing simply stays cheaper.
The UI is unstable
The test breaks faster than you can maintain it. You end up maintaining a suite instead of shipping software.
The rule of thumb
If you take one thing away from this article, let it be this:
That's not dogma, it's a filter. Meet all three, and the business case is almost always positive. Miss one, and calculate it before you start. Miss two, and you already know enough.
With test automation your team buys back time. No endless manual regressions eating into every sprint, but room to build what actually adds value, or to go deeper where it counts. That's the payoff. The formula just helps you figure out where to find it.
Enter your own build time, maintenance and manual test time and see your break-even point instantly.
Curious what this means for your suite?
We'll go through your test set with you and work out what automating actually delivers. And what's better left manual.
Book a call