TestingBudget

Run

Machine time per run

How long a tool takes to execute the whole suite — duration, deliberately not cost.

Unit
hours per run, derived
Where you enter it
Computed; shown on the Run tab for automation vendors.

What it means

Total cases multiplied by the execution time per case, for an automation vendor. It tells you whether a full regression fits in a pipeline window or an overnight slot, and it is reported for exactly that reason. It is not a labour cost: no one is paid while the machine runs, and the model never converts it to money.

It does not apply to a manual approach, whose execution time is the tester's and is counted as effort instead.

Why it matters to the cost

The old way of costing automation multiplied machine time by a "supervision percentage" and called the result labour, which quietly charged for time nobody spent. Keeping machine time separate makes the human cost honest and still answers the practical question — a ten-hour run cannot happen on every commit.

Typical values

Ten to fifteen hours of serial machine time for a 300-case suite at two to three minutes a case; parallel execution divides it.

Typical values describe a category of tool — AI-native, codeless, script-based, homegrown, manual — never a named product. Why we do not price named products.

Where it appears in the model

Run — every release

tests broken per run
Total test cases × Test breakage rate ÷ Runs per year — found here, repaired under Maintain
Failures per run
Defects found per run + tests broken per run + flaky per run — derived, never asked
Machine time per run
Total test cases × Execution time per case — automation only; duration, not labour

Every name is a link to its definition. See the whole model.

Try it with your numbers

Machine time per run is a row in the calculator. Change it and every total on the page moves with it — free, in your browser, nothing to install.

See how machine time per run impacts the calculation of test automation costs

Last reviewed 2026-09-15. All terms.