Build
Scoping the suite
The one-off analysis to decide how many test cases the application needs and which ones — done once, whichever tool builds them.
- Unit
- hours, one-time
- Where you enter it
- Build tab, Detailed mode, "All vendors" column.
What it means
Working out what to automate: reviewing the application's functionality and risk, deciding the regression scope, and arriving at the case count by tier. It is a property of the application and the team's knowledge of it, not of any tool, so it is entered once per application and folded into every vendor's build cost.
It is the first activity in the Build phase and usually precedes the vendor decision.
Why it matters to the cost
Scoping is the same cost whichever tool wins, so it never changes the ranking — but leaving it out understates every vendor's year-one figure equally, which matters when the comparison is against not automating at all.
Typical values
One to three days for a single application; a week or more for a large packaged-application estate.
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
- Build cost
- Build effort × Effective hourly rate + Build tokens priced as Token cost
Every name is a link to its definition. See the whole model.
Try it with your numbers
Scoping the suite 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 scoping the suite impacts the calculation of test automation costsLast reviewed 2026-09-15. All terms.