test automation modelled effort · calculator

TAME Calculator

The two-stage effort-hours model, live.

Creation inputs
%
%
Execution inputs
%
%
Context modifiers σ · ρ · κ (§10)
Creation (one-time)
Manual baseline133.3 h
AI + review51.5 h
Accuracy ceiling64%
Saved61%
Execution (12 cycles)
Manual baseline960.0 h
Automated713.6 h
· of which scripting (once)280.0 h
Break-even (effort)6.4 cyc
Combined program
Manual total1093.3 h
New total765.1 h
Saved328.3 h
Program saving30%
Effort-hours only; throughput & quality gains are separate (§15). Defaults are illustrative — calibrate (§14).TAME paper ↗ · Download PDF

About the TAME calculator

TAME — Test Automation Modelled Effort — answers a question most automation business cases skip: how many effort-hours does the new process actually remove, and how does that change as the work repeats? It separates the one-time creation stage from the recurring execution stage, because their economics are completely different, and reports effort-hours rather than a vague percentage.

How it works

  1. 1Set your creation inputsSuite size, authoring time per case, AI review and rework time, and the miss rate — how often the AI fails to produce a usable case.
  2. 2Set your execution inputsAutomation coverage, scripting time per case, manual execution time per cycle, triage and maintenance, and how many regression cycles you run.
  3. 3Read the two verdictsCreation saving is bounded by accuracy, not speed: if the AI misses 20% of cases, the saving cannot exceed 80% however fast review becomes. Execution saving compounds with cycles and has a break-even point that is independent of suite size.
  4. 4Add the context that changes the answerSeniority, governance overhead, and tool fluency multiply rather than add, and the scripting learning curve is modelled explicitly. In a governed environment the verdict can flip from negative to strongly positive.

What you get

Who it's for

QA leads and delivery managers building an automation business case, and programme leads who need the claim in a vendor deck checked against a model whose formulas are published in full.

Common questions

Why effort-hours instead of a percentage faster?
Because a percentage hides where the saving comes from. Creation is paid once; execution is paid every cycle. Blending them into one number obscures the break-even, which is the thing a business case actually turns on.
Does it count the faster wall-clock time of an unattended run?
No, deliberately. The model reports human effort only. An overnight run finishing sooner is a real throughput benefit, but counting it as effort saved would inflate the number.
Are the default values recommendations?
No. They are placeholders chosen to make the worked examples concrete. Substitute your own measured figures before drawing any conclusion — different inputs give different results, by design.
Where can I check the maths?
The full methodology paper publishes every formula, a symbol table, and an end-to-end worked example, and it is available as a PDF.

Related