The QA Budget Line Items Nobody Forecasts Until Year Two

Ask most engineering leaders how they built their QA budget, and you'll hear a version of the same story. They priced out a tool, added a couple of licenses, budgeted a contractor or two to write the initial test suite, and called it done. The number looked reasonable. Finance approved it without much friction, because compared to headcount or infrastructure spend, QA tooling is usually a rounding error in year one.

Then year two arrives, and the same team is explaining why the "automation savings" line item somehow needs more budget, not less.

This isn't a planning failure in the way most people assume. It's a structural gap in how QA budgets typically get built in the first place: as a procurement decision instead of a lifecycle cost. A license fee is easy to forecast. Maintenance, headcount growth, flaky-test triage, and tool sprawl are not, mostly because nobody puts them on the spreadsheet until they've already shown up as a problem.

Why Year-One Budgets Look Deceptively Simple

A first-year automation budget is usually built from a short list: license or subscription cost, setup or onboarding time, and maybe a contractor to write the initial scripts. All three are quotable. A vendor gives you a number, a contractor gives you a rate, and the whole thing fits neatly into a one-time capital-style request.

What doesn't fit into that request is the ongoing cost of keeping the suite useful after it ships. That's not because teams are careless. It is because maintenance cost doesn't really exist yet in year one. The suite is new, the application hasn't drifted much from what the tests expect, and everything looks stable. The bill for that stability comes later, once the UI has been redesigned twice, the team has onboarded three new engineers who didn't write the original tests, and the suite has grown past whatever size it was when someone last reviewed it end to end.

In practice, the teams that get surprised in year two aren't the ones who forecasted badly. They are the ones who never had a line item for maintenance at all, because the initial budget process was built around buying a tool, not owning a testing system.

What Actually Shows Up in Year Two

A few costs tend to arrive at roughly the same time, which is part of why they hit hard when finance reviews the renewal.

Maintenance work becomes a real line item. Every UI change, every refactor, every new release path breaks some percentage of an existing suite. Someone must update selectors, rewrite assertions, and figure out whether a failing test caught a real bug or just a renamed CSS class. This work rarely gets its own budget category. Instead it quietly consumes engineer time that was supposed to go toward new coverage.

Flaky tests start taxing the whole team, not just QA. A test that fails for reasons unrelated to the actual feature doesn't just cost the person who wrote it. It costs everyone watching that pipeline, because a failed build gets investigated before anyone trusts it enough to ignore. Multiply a few minutes of "is this real" across every engineer on every failed run, and it adds up to a meaningful chunk of a work week across a team, even though it never appears as a distinct budget line.

Headcount pressure shows up before anyone planned for it. A suite built by two engineers in year one usually needs more hands by year two, not because coverage doubled cleanly, but because maintenance work scales with suite size in a way that new coverage work doesn't. Teams often discover this the hard way: they hired for feature velocity, and the automation suite quietly became someone's full-time job anyway.

Tool sprawl creeps in. The original platform doesn't cover something the team now needs (visual testing, API contract checks, mobile), so a second tool gets purchased to fill the gap. Now there are two licenses, two learning curves, and two places test results live, which makes reporting and traceability harder instead of easier.

Training and onboarding cost repeats every time someone leaves. A framework-heavy automation suite has a real ramp-up period. When the one or two engineers who understand the suite's structure move on, that knowledge often leaves with them, and the replacement's ramp-up time becomes an unbudgeted cost all over again.

None of these are exotic. They're the ordinary cost of running software that has to keep working as the product underneath it changes. The problem is that almost none of them show up in a year-one procurement conversation.

What the Data Actually Shows

It's worth grounding this in something more concrete than anecdote. Capgemini's long-running World Quality Report series, the industry's largest recurring survey on quality engineering practices, has tracked QA and testing spend as a share of overall IT budget for well over a decade. Across earlier editions of that research, reported QA spend climbed from around 18 percent of IT budget to the mid-30s over a period of several years, driven largely by the shift toward continuous testing and DevOps. The exact figure moves year to year and varies heavily by industry and org size, but the direction has been consistent: QA's share of spend rises as delivery speeds up, not the other way around.

On the maintenance side specifically, independent cost analyses in the test-automation space converge on a surprisingly consistent range: maintenance work commonly consumes somewhere between 30 and 50 percent of an ongoing automation budget, once a suite matures past its first release. That range holds up across several separate cost breakdowns from different vendors and consultancies, which is a reasonable signal that it isn't a one-off outlier.

Put plainly: if a team's year-one budget only accounts for build cost, it's missing what is very often close to half of what that suite will cost to run going forward.

A Worked Example

To make this concrete, picture a mid-size SaaS company with roughly forty engineers and a QA function of two automation engineers. In year one, they budget for a commercial automation tool, a handful of licenses, and about ten weeks of contractor time to build out a 300-test regression suite covering the core product flows. The number finance approves looks clean: tooling plus a fixed build cost.

By month fourteen, the picture looks different. Two product redesigns have broken roughly a third of the original selectors. One of the two automation engineers is now spending close to half their week on triage and repair rather than writing new tests. A mobile release added a testing need the original tool doesn't cover well, so the team is evaluating a second platform. And the person who built most of the original framework just left, which means onboarding time for their replacement is now a real, if unbudgeted, cost.

None of this is unusual. It's what typically happens when a testing budget is planned around what it costs to build a suite instead of what it costs to keep one alive. The fix isn't a bigger initial budget. It's a different model for what gets budgeted in the first place.

Building a Cost-Per-Release Model Instead of a Cost-Per-Tool Model

Most QA budgets are structured around the tool: what does the license cost, what does the contractor cost, what's the total for year one. A more durable approach is to budget around the release, because that's the unit the business actually cares about and the unit costs actually track against.

A cost-per-release model asks a narrower, more useful question: what does it cost, in engineer time and tooling, to get one release safely out the door, including the maintenance and triage work that release inevitably generates. That number is harder to pull from a vendor quote, but it's the number that predicts what next year's budget request needs to look like.

Building it doesn't require exotic finance skills. It requires tracking, even roughly, how much engineer time goes into three buckets across a quarter: writing new coverage, maintaining existing coverage, and triaging failures that turn out not to be real bugs. Most teams have never split time this way, which is exactly why the year-two number surprises them. 

Once you have even a rough split, forecasting the next year's automation maintenance budget becomes a straightforward extrapolation instead of a guess, and it becomes much easier to answer the question every finance team eventually asks: what percentage of engineering budget should go to QA, and why does that number keep climbing after the first year.

QA headcount planning follows the same logic. Instead of hiring reactively when maintenance backlog gets visible, teams that track this ratio can forecast when a second automation engineer becomes necessary, tying the hire to suite size and defect-escape rate rather than to how loud the complaints have gotten.

Where the Cost Structure Actually Changes

Most of the year-two costs above trace back to the same root cause: a test suite that was built against one interaction with the application, at one point in time, and has no independent way of knowing when that interaction is out of date. Every UI change becomes a guessing game about what broke and why, and every fix is manual, because nothing in the system understands the application well enough to adapt on its own.

This is the argument behind self-healing test automation: a meaningful share of year-two maintenance cost isn't really a testing problem, it's a brittleness problem, and brittleness is something a platform can be designed to reduce rather than something a team has to absorb manually forever.

TestMax approaches this from a slightly different angle than most tools by starting from the requirement rather than a single recorded interaction, and by maintaining a live map of the application itself rather than a fixed set of selectors captured once. 

When the UI changes, the platform can check the current state of the application against that map before deciding a test needs a person to fix it, which is a different cost structure than every UI change generates a support ticket for a human. It doesn't eliminate maintenance entirely. Nothing does. But it changes which parts of maintenance require a person and which don't, and that ratio is most of what drives the year-two number up or down.

The same logic applies to traceability and reporting overhead. When requirements, test cases, scripts, and execution results stay connected automatically instead of being reconstructed by hand for an audit or a leadership update, that's engineer time that doesn't need budgeting as a recurring cost, because it was never a recurring task to begin with. For teams in regulated environments, that traceability requirement is not optional, and the hidden compliance overhead of maintaining it manually is itself a line item worth putting a number on before year two, not after.

None of this makes the maintenance question disappear from a budget conversation. It's still worth asking a vendor directly what percentage of a typical customer's year-two spend goes to maintenance versus new coverage, and it's a fair question to ask about the total cost of any AI test automation platform, not just the sticker price. A platform that quietly shifts maintenance cost into a subscription fee instead of engineer time hasn't necessarily made the cost disappear. It's worth understanding which of those two you're actually paying for.

A Simple Forecasting Checklist for Year Two

Before finalizing next year's QA budget, it's worth running through a short list of questions most teams skip:

• What percentage of automation engineer time went to maintenance versus new coverage last quarter, even as a rough estimate?
• How many hours per week does the team collectively spend triaging failures that turn out to be flaky rather than real?
• Has the application gone through a redesign, framework migration, or major refactor in the last twelve months that the current suite hasn't fully absorbed yet?
• If the person who understands the automation framework best left tomorrow, how long would onboarding a replacement take?
• Is there a second tool being evaluated to cover a gap the first one doesn't, and has that cost been modeled as a recurring line rather than a one-time purchase?

None of these questions require sophisticated tooling to answer. They require someone to track the split between building and maintaining, which most teams don't do until the maintenance cost is already large enough to notice on its own.

The Budget Conversation Worth Having Now

A QA budget built entirely around procurement will always look artificially low in year one and artificially surprising in year two, because the real cost of test automation was never really about the license. It's about what it takes to keep a suite trustworthy as the product underneath it keeps changing, and that cost doesn't show up on an invoice. It shows up in engineer calendars.

Teams that forecast this well don't necessarily spend less. They spend the same money with fewer surprises, because they've separated build cost from run cost early enough for it to change next year's budget request instead of explaining last year's overage.

If you're building out a QA budget for the year ahead and want to see what a requirement-driven approach to test maintenance actually looks like against your own application, TestMax offers a demo that walks through how the platform handles application changes without turning every release into a manual repair cycle.

FAQs

What should a QA budget include for the second year?

Beyond licensing and initial build cost, a realistic second-year QA budget should include ongoing maintenance work (commonly 30 to 50 percent of the automation budget once a suite matures), time spent triaging flaky test failures, onboarding cost for any new automation hires, and any additional tooling needed to cover gaps the original platform doesn't address. Most first-year budgets only account for the first category.

How much does test automation maintenance cost annually?

There's no single fixed number, since it depends heavily on how often the application's UI changes and how the original suite was built. Multiple independent industry cost analyses put maintenance in the range of 30 to 50 percent of an automation program's ongoing budget, which for a team spending meaningfully on tooling and engineer time can mean maintenance costs approach or exceed the original build cost within a year or two.

How do you forecast QA costs as a team scales?

The most reliable approach is tracking a cost-per-release figure rather than a cost-per-tool figure: how much engineer time and tooling spend goes into shipping one release safely, including maintenance and triage. Teams that split engineer time into build, maintain, and triage buckets, even roughly, can extrapolate next year's budget instead of guessing at it.

What percentage of engineering budget should go to QA?

Industry benchmarks vary by sector and maturity, but Capgemini's World Quality Report has tracked QA and testing spend rising from around 18 percent of IT budget toward the mid-30s over the past decade as continuous delivery practices spread. The right number for any specific team depends on release frequency, regulatory requirements, and how much manual testing still remains in the process, so it's better used as a directional benchmark than a fixed target.

Why do test automation costs increase after the first year?

Costs rise because year-one budgets typically only price the build: licenses, setup, and initial scripting. Maintenance cost barely exists in year one because the suite is new and the application hasn't drifted from what the tests expect. By year two, UI changes, team turnover, and suite growth all generate real, recurring costs that were never modeled in the original budget request.