Build
People trained
How many people will be trained on the tool — the multiplier on training time per person.
- Unit
- count
- Where you enter it
- Build tab, Detailed mode, per vendor.
What it means
The head-count that needs to learn the tool well enough to author and maintain cases: usually the testers who will own the suite, sometimes developers who will contribute, occasionally a wider group for review and triage.
It is per vendor because the pool can differ — a codeless tool may be rolled out to a whole QA team where a code-first framework would be limited to a few engineers.
Why it matters to the cost
Multiplied by the training hours, this decides whether training is a rounding error or a line item. It is also a sanity check on the plan: a suite that only two trained people can maintain is a key-person risk that no cost model shows directly.
Typical values
Three to ten for a single application; more for a shared platform team.
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
People trained 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 people trained impacts the calculation of test automation costsLast reviewed 2026-09-15. All terms.