When comparing system development estimates side by side, there is one line item where eyes inevitably stop: testing effort. While implementation hours per screen and feature are broken down in detail, testing is grouped into a single lump sum. Even though the price can account for 20% to 40% of the entire budget, there is no breakdown.
Unable to tell whether it is expensive or reasonable, clients end up approving it as-is. Or they ask, "Testing looks expensive, can we cut it down?" and end up cutting things that must never be removed. Both outcomes stem from lacking clues to decipher the estimate.
Testing effort can actually be estimated using just two multiplications. When the purchasing side has this framework, you can ask concrete, pointed questions about the estimate.
First Multiplication: How Many Cases Will Be Tested?
The first figure to calculate is neither price nor hours, but the number of test cases.
推定ケース数 = ストーリーポイント × テスト密度Story points quantify the scope of features being developed. Teams working in Agile already track this. Test density is a coefficient representing how many test cases that team has historically written per story point.
Calculating density is straightforward: divide the total test cases over the last few sprints by the total story points completed during the same period. Data from three to five sprints provides a sufficiently stable coefficient.
Here is the crucial point: test density is not an industry standard metric, but a number unique to that team. Even for features of identical scale, required test cases fluctuate depending on the domain and quality requirements. Comparing against "industry averages" is meaningless; it is only meaningful when compared against that specific team's historical track record.
Second Multiplication: How Long Does Each Case Take?
Once the number of cases is established, the next step is execution time.
推定実行時間 = ケース数 × 複雑度別の所要時間Weighing all cases equally leads to inaccurate estimates. A simple input validation check carries a completely different weight compared to verifying an end-to-end business flow across external systems. Classify them into roughly three levels of complexity, and multiply by their respective execution times.
Execution times per complexity level must also be derived from historical performance. Multiplying numbers based on intuition ceases to be a verification and simply turns into another arbitrary estimate.
What the Client Should Ask Regarding the Estimate
Equipped with this formula, the nature of your questions changes. Instead of asking "Testing is expensive, please lower it," you ask the following two questions:
"How does this test density compare with your team's historical track record?"
If they can answer, you know the estimate is grounded in empirical performance. If the answer is "this is roughly the industry standard," that estimate is likely an unfounded buffer figure rather than an empirical projection. Conversely, if an unusually low density is returned, you can suspect the pricing assumes inadequate testing.
"What percentage of the total do high-complexity cases account for?"
This is the most impactful question in practice. An estimate where complexity breakdown cannot be answered was not conceived at the case-level granularity. And when additional invoices arise mid-development because "integration proved heavier than expected," it is almost always due to flawed projections in this area.
The easiest way to make an estimate look inexpensive is to underestimate high-complexity cases. Cheap at signing, ballooning before acceptance. Think of this question as your defense against that scenario.
The Right Way to "Cut Testing"
Trimming testing when budgets do not align can be a legitimate business decision. The problem lies in how it is cut.
| Common ways to cut testing | What actually happens |
|---|---|
| Cutting testing hours uniformly by 20% | Nobody knows which cases were eliminated |
| "Deferring automated tests until later" | Manual regression testing remains as an ongoing maintenance cost every time |
| Narrowing target features to reduce case count | The eliminated scope is explicit, allowing risks to be acknowledged |
Only the third option is acceptable. When thinking on a case-count basis, you can designate exactly what to cut; cutting on a monetary basis leaves you blind to what vanished. The practical value of breaking down costs with two multiplications lies here, not in aggressive price bargaining.
Furthermore, simply increasing case count does not automatically improve quality. Bugs frequently persist even when meeting coverage goals, so teams must share the baseline assumption that case volume is a necessary condition, not a sufficient one.
Scenarios Where Estimation Assumptions Collapse
There are situations where this method does not apply: when no historical track record exists. When working with a new partner or venturing into an unfamiliar domain, the test density coefficient itself simply does not exist.
In that case, the viable approach is to treat the first few sprints as a period to measure baseline coefficients. Rather than estimating the whole project as a single lump sum, establish track records in the initial milestone and re-estimate the remainder. Deciding between Agile and Waterfall approaches also hinges on whether you have this coefficient in hand.
Additionally, for estimates including automated testing, confirm that authoring effort and maintenance effort are separated. Many reasons why test automation fails to take root trace back to estimating only initial creation while allocating nobody's hours to maintaining broken tests.
What to do next
Open an estimate you have on hand and check whether testing effort is written as a lump sum. If it is listed as a lump sum, pose the two questions above directly. The specificity of their answers will serve as a direct gauge of their estimation accuracy.
If your company has past development records, aggregate the test cases and story points from the last three sprints. Obtaining just one in-house coefficient will change how you read development estimates on your very next procurement.
GleamHub offers development estimate reviews, quality requirement design, and testing effort validation for ongoing projects through our custom development, AI, and automation consultations. What to inspect depends on project scale and current team structures, so please reach out via our inquiry form.
