Build
Total test cases
The number of test cases in the regression suite being costed — the scale every other figure multiplies against.
- Unit
- count
- Where you enter it
- Build tab, "All vendors" column. Simple mode as one number; Detailed mode as three tiers.
What it means
The size of the suite under evaluation: how many test cases will be built, executed every run, and kept working as the product changes. It belongs to the application, not to any tool, so it is entered once and every vendor column sees the same figure.
In Detailed mode it is the sum of the three complexity tiers. In Simple mode it is entered directly and distributed across the tiers behind the scenes so the same engine runs in both modes.
Why it matters to the cost
Almost every cost line is per case, so this is the multiplier on all of them. Doubling the suite from 300 to 600 cases doubles authoring effort, doubles the tests exposed to breakage each year, and doubles what a run has to execute — while licence and infrastructure costs stay flat. That is why a vendor that looks expensive on a 100-case pilot can look cheap at 1,000, and vice versa.
Typical values
A single business application is commonly regression-tested with 200 to 800 cases; a large packaged-application estate can carry several thousand. The default scenario uses 300.
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
Build — one-off
- Total test cases
- basic + average + complex Test case complexity tiers
- Build effort
- Set up, install and configure + Scoping the suite + Training time per person × People trained
- + Σ Test case complexity tiers × Build time per test case for each tier, as Scratch vs migration
- + Total test cases × Validate a built case
- Build cost
- Build effort × Effective hourly rate + Build tokens priced as Token cost
Run — every release
- tests broken per run
- Total test cases × Test breakage rate ÷ Runs per year — found here, repaired under Maintain
- flaky per run
- Total test cases × Flaky failures per run
- Failures per run
- Defects found per run + tests broken per run + flaky per run — derived, never asked
- Run effort
- Prepare and start a run + Failures per run × Triage one failure + Defects found per run × Write up one defect + Report and sign off — an automation tool
- Run effort
- Prepare and start a run + Total test cases × Execution time per case + Defects found per run × Write up one defect + Report and sign off — a manual approach — the tester is the run
- Machine time per run
- Total test cases × Execution time per case — automation only; duration, not labour
- Run cost per year
- Run effort per run × Runs per year × Effective hourly rate + Token cost
Maintain — continuously
- cases to repair
- Total test cases × Test breakage rate
- cases healed
- Total test cases × Self-healed cases per year
- Maintenance effort per year
- cases to repair × Repair time per case + cases healed × Review one heal + Platform upkeep per year + New cases added per year × Build a new case
Every name is a link to its definition. See the whole model.
Try it with your numbers
Total test cases 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 total test cases impacts the calculation of test automation costsLast reviewed 2026-09-15. All terms.