How the model works

Cost lives in three phases

A suite is paid for three times: once to build, every release to run, and continuously to keep working. The licence is usually the smallest of the four.

Build — one-off

Authoring dominates. The gap between a codeless tool at fifteen minutes a case and a hand-written framework at four hours is, across a few hundred cases, measured in person-months.

Run — every release

Human effort is priced as what the person does, never as a share of machine time. For a tool, execution is machine time — it decides how long a run takes, not what it costs. The cost is everything a person has to do afterwards: look at each failure and decide whether it is a real defect, a broken test, an environment problem or a flake; write up the real ones; sign the run off. That deciding and writing up is defect validation, and the failures it rejects are the false positives — broken tests and flakes — that cost triage time whichever tool produced them. Failures are never asked for — they are derived from three things: how many bugs a cycle finds (a property of your product, entered once), how many tests the product broke (Maintain's breakage rate, spread over the year's runs), and the tool's flake rate. A run finds broken tests; Maintain fixes them, so nothing is counted twice. For a manual approach the tester is the run, so execution is counted in full, and there is no separate triage — the person decides what a failure means as they go. The vendor's kind, manual or automation, selects which formula applies; nothing is asked twice.

Maintain — continuously

When a vendor claims self-healing, or fewer false positives, they are claiming a lower breakage rate. This is where you put a value on that claim: reduce the rate from 30% to 10% and the five-year total moves accordingly. What healing does not remove is the person. Current practice is that every automatic repair is reviewed before it is trusted, so a heal is priced as a short review rather than as nothing.

Turning effort into cost

A division that meets a legitimate zero — no FTEs budgeted, no runs a year — shows a dash. A number that cannot be computed is never shown as zero.

Licences are counted once, not once per application

Licence and infrastructure belong to the vendor, not the application. Summing them per application bills the same enterprise licence four times over on a four-app estate, which favours whichever tool has the smallest licence.

Aggregates count them once. Per-application views show an apportioned share, allocated by that app's share of total cases and labelled as allocated. The shares sum back to the total; a test asserts it.

Adding it up

The build lands entirely in year one; everything else recurs for each year of the analysis horizon. That is why the cumulative chart matters more than any single year: it is where a tool with the higher licence and the lower maintenance overtakes the cheaper licence.

Build duration is a workspace-level question

Applications compete for the same people, so a per-application duration is a comfortable number and an impossible plan. Where the build outruns the gap between releases, or needs more engineers than are budgeted, the model flags it.

Why we do not price named products

Cost estimates describe a category of tool — AI-native, codeless, script-based, homegrown, manual — never a named product. Comparison pages name vendors and state sourced facts about them. They do not attach a price to a name.

A site that priced a named company's software could not be neutral ground: any vendor that lost such an evaluation could argue the numbers were weighted against them. You assign the category, so the only prices in your comparison are the ones you entered.

The default scenario

Figures on comparison pages describe this suite unless a page says otherwise:

• One application with 300 test cases (90 basic, 150 average, 60 complex).
• 12 full regression runs a year, each finding about 5 defects.
• 40 new cases added a year as the product grows.
• A loaded cost of $120k per engineer per year across 1800 working hours.
• A 5-year horizon.

It is a generic mid-size estate, chosen to be recognisable rather than favourable to anything. Open the Calculator to replace it with yours.

What the model leaves out

It counts labour, licensing, infrastructure and AI token spend. It does not price the quality outcomes that are usually the actual reason to automate: defects that reach production, incidents avoided, and the release velocity a faster feedback loop buys.

Those are real and often larger than the labour saving. Leaving them out understates the case for automation, which is the right direction of error for a number you have to defend in front of a finance function — but say so when you present it, because someone will ask.

Three things are excluded deliberately: discounted cash flow, confidence ranges and sensitivity analysis. Discounting is not how organisations choose a test tool, and the other two double the input burden for a degree of precision the underlying estimates do not support.