Test Estimation Techniques: Five Methods Compared

Why estimates go wrong

Test estimates fail for three reasons: the scope is not fixed when the estimate is made, the estimate covers execution but forgets analysis, environment setup and retesting, and nobody records the actuals so the next estimate starts from the same guess. Every technique below is a way to force the scope into view and to produce a number you can compare with the actual afterwards. The fundamental test process gives the activity list that the estimate has to cover: planning, analysis, design, implementation, execution and completion.

Work breakdown

List every task, estimate each in hours, sum, then add contingency. For a release with 120 test cases across four features: test analysis and condition identification, 40 hours. Test design at 30 minutes per case, 60 hours. Implementation, meaning data preparation, environment configuration and scripting, 40 hours. Execution at 15 minutes per case over two full cycles, 60 hours. Defect retest and confirmation, 40 hours. Reporting and completion, 12 hours. Total 252 hours. Add 15 percent contingency for the unknowns you know exist: 290 hours. Work breakdown is the most transparent method and the easiest to defend line by line, but it takes half a day to produce and is only as good as the task list.

Three-point estimation

For each work package take an optimistic estimate O, a most likely estimate M and a pessimistic estimate P. The expected value is E = (O + 4M + P) / 6 and the standard deviation is (P minus O) / 6. For the payment feature in the figure: O is 8 days, M is 12, P is 30. E = (8 + 48 + 30) / 6 = 14.3 days, standard deviation 3.7 days. Quoting the estimate as 14 days plus or minus 7 (two standard deviations, roughly 95 percent confidence) tells the sponsor how uncertain you are, which a single number never does. Summing E across four features gives the release estimate; summing the variances and taking the square root gives its spread. Three-point takes an hour per feature and is the best method for communicating uncertainty.

Test point analysis

Test point analysis sizes testing from the functional size of the system. Start with function points per feature from the requirements, adjust each for quality requirements (complexity, interfacing, uniformity, and the importance of the quality characteristics being tested) to get dynamic test points, add static test points for reviews, then multiply by a productivity factor in hours per test point that comes from your own history. For the worked release: 320 function points adjusted to about 400 test points, at 1.2 hours per test point, gives 480 hours of primary testing. Environment and team factors then adjust the total. Test point analysis is the most rigorous method and the only one that scales to a large program, but it needs function point counts and a calibrated productivity figure, which most teams do not have on day one.

Percentage of development effort

Take the development estimate and apply a ratio. Historical ratios for system-level testing sit between 25 and 40 percent of development effort, lower for mature products with strong unit testing and higher for new products, integration-heavy work or regulated domains. For the worked release with 1,600 development hours, 30 percent gives 480 hours. This takes ten minutes and is useful for a first budget conversation. It is dangerous as a final estimate because it inherits every error in the development estimate and knows nothing about risk.

Planning poker

The team estimates each story in relative points by consensus, with testing included in the story, and the sprint capacity in points is known from velocity. Testing effort is not separated, which is the point: the story is not done until it is tested. For a team with a velocity of 40 points and the release backlog at 190 points, the release takes about five sprints. Planning poker is fast, involves the whole team and improves with every sprint of actuals. It gives no hours figure for a sponsor who wants one, and it says nothing about test effort outside the sprint such as performance testing or a release regression.

Five techniques for the same 480-hour release. Work breakdown came in lowest at 290 hours because its task list did not include performance or security testing; that gap is the lesson.
Technique	Inputs	Accuracy	Effort to produce	Best for
Work breakdown	Task list, hours per task, contingency	Good if the task list is complete; misses unknown unknowns	Half a day per release	Plans that need a line-by-line justification
Three-point	O, M and P per work package	Good; gives a range and a confidence level	One hour per feature	Communicating uncertainty to sponsors
Test point analysis	Function points, quality factors, productivity history	Best once calibrated; poor without history	One to two days plus a counting skill	Large programs, outsourced or fixed-price testing
Percentage of development effort	Development estimate, historical ratio	Rough; inherits development estimate errors	Ten minutes	Early budget conversations
Planning poker	Stories, team, velocity	Good for sprints; nothing for out-of-sprint testing	Two hours per backlog refinement	Agile teams estimating stories that include testing

Combining techniques

Use two techniques and compare. When work breakdown says 290 hours and the percentage method says 480, the difference is a list of things the breakdown forgot, in this case non-functional testing and a third execution cycle. Reconcile them, record the reasoning, and quote a range rather than a point. Then record the actual at release. After three releases you have a productivity figure and a ratio that belong to your team, and the estimate gets better without any new technique. Feed the risk class of each feature into the breakdown: high-risk features carry more design and execution hours per case, and the estimate should show it.

Quote a range

An estimate of 480 hours will be treated as a promise. An estimate of 420 to 560 hours with the reason for the spread will be treated as information. The second is more accurate and gets you a better conversation.

Common questions

Which test estimation technique is most accurate?

Test point analysis once it is calibrated with your own productivity data, then three-point for individual features. Without history, three-point plus a work breakdown is the most reliable pairing.

What percentage of development effort should testing take?

Between 25 and 40 percent for system-level testing, depending on product maturity and risk. Regulated or safety-related work can exceed 50 percent. Treat the ratio as a check, not an estimate.

How do you estimate testing in agile?

Estimate stories in points with testing included, and track velocity. Estimate out-of-sprint testing, such as release regression and performance runs, separately with a work breakdown.

What is the three-point estimation formula?

E = (O + 4M + P) / 6, where O is optimistic, M is most likely and P is pessimistic. The standard deviation is (P minus O) / 6. It comes from the PERT method and weights the most likely value four times.

Why are test estimates always too low?

Because they cover execution and forget analysis, environment setup, retesting after fixes and the third execution cycle. A complete activity list from the fundamental test process fixes most of it.

How much contingency should a test estimate include?

Fifteen percent for a known team and stable scope, 25 to 30 percent for a new team, a new domain or a scope that is still moving. Show it as a separate line rather than hiding it in the tasks.

Test estimation: five techniques with worked numbers