Maintain
New cases added per year
Suite growth: how many new test cases the application gains each year as it acquires features.
- Unit
- count per year
- Where you enter it
- Maintain tab, "All vendors" column.
What it means
A suite is not built once. Every release adds functionality that needs coverage, and those new cases cost authoring time every year. The number belongs to the application — how fast the product is changing — so it is entered once and applies to every vendor.
Multiplied by the build-a-new-case time, it is the growth term in maintenance effort.
Why it matters to the cost
Growth is the maintenance cost people forget because it feels like build. Forty new cases a year at a two-hour average is 80 hours annually — comparable to the repair line — and it favours the tools with fast authoring for exactly the same reason the initial build does.
Typical values
Ten to fifteen percent of the suite per year for a product in active development; the default scenario uses 40 on 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
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
New cases added per year 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 new cases added per year impacts the calculation of test automation costsLast reviewed 2026-09-15. All terms.