Test Estimation Techniques Explained

Why test estimates fail

Most estimate failures are not arithmetic errors. They come from estimating the wrong thing or from treating a guess as a commitment. Testing is especially exposed because part of its effort depends on something nobody knows in advance: how many defects the product contains and how long they take to fix and re-test.

• Only execution is estimated — test analysis and design, environment and data setup, automation maintenance, defect retesting, regression runs and reporting are forgotten.
• A single number is given and then heard as a promise, although it was only the most likely case.
• The estimate is anchored on the deadline: the answer is worked backwards from the date instead of forwards from the scope.
• Rework is ignored — the plan assumes the first build is good enough to test and that each defect is re-tested once.
• Dependencies on other teams (builds, environments, third-party sandboxes) are not written down, so their delays look like testing overruns.
• Scope changes but the estimate does not.
• The person who estimates is not the person who will do the work, and there is no historical data to compare with.

Factors that drive testing effort

The ISTQB Foundation syllabus (in its 2018 edition) grouped the factors that influence test effort into four families. The grouping is still a useful checklist: before accepting any number, ask how each factor applies to this scope.

• Product — size and complexity, the quality of the test basis (clear requirements or vague ones), the quality characteristics that must be tested (security, performance, accessibility), required documentation for audit, the number of platforms, devices and languages (Arabic and English, right-to-left layouts), and integrations with external systems.
• Process — the lifecycle model, the maturity of the test process, tool and automation support, availability and stability of environments, and time pressure.
• People — skills and domain experience of the testers and developers, team stability, and how well the team works together.
• Test results — the number and severity of defects found and the amount of rework they cause; a buggy build multiplies re-testing and regression effort.

Try it: Risk-Based Test Generator Try it: AI Risk-Based Test Generator

Metrics-based techniques: ratios and extrapolation

The ISTQB CTFL v4.0 syllabus describes four estimation techniques: estimation based on ratios, extrapolation, Wideband Delphi and three-point estimation. The first two are metrics-based and need historical or current data from your own organisation — numbers from another company or an industry average are a poor substitute.

Ratio-based estimation applies a ratio observed in past projects to the new one. For example, if over the last four releases testing effort was 0.38, 0.42, 0.45 and 0.35 of development effort (average 0.40), and development estimates the new release at 70 person-days, the ratio suggests about 28 person-days of testing. The ratio is only valid for similar work: a release with a new payment integration is not similar to one of UI text changes.

Extrapolation uses measurements from the current project to predict the rest of it. For example, after four days of the first execution cycle a team has executed 48 of 130 planned tests, about 12 per day, and found 9 defects. At that rate the remaining 82 tests need about 7 more days — before the re-testing those 9 defects (and the ones still to come) will cause. Extrapolation becomes more reliable as the project progresses, which makes it the natural technique for re-estimation.

Try it: Requirements → Test Cases

Expert-based techniques: Wideband Delphi and planning poker

When there is little historical data, structured expert judgement works better than one person’s guess. Wideband Delphi is an iterative technique in which experts estimate independently, compare, discuss the reasons behind the differences, and estimate again until the estimates converge or the remaining spread is understood.

Planning poker is widely used in agile teams and is commonly described as a variant of Wideband Delphi. Each member holds cards with values (often a modified Fibonacci series such as 1, 2, 3, 5, 8, 13), everyone reveals an estimate for a user story at the same time, and the highest and lowest estimators explain their reasoning before the team votes again. Estimates are usually relative story points for the whole story, so testing effort is part of the story’s size rather than a separate number — which is exactly why testers must be in the room: a story that is trivial to build can be expensive to test.

• 1. The coordinator presents the scope and the assumptions to all estimators.
• 2. Each expert estimates alone and writes down their assumptions.
• 3. Estimates are shown together, without attributing them if the group prefers.
• 4. The outliers explain what they know or assume that others do not; this discussion is where most of the value lies.
• 5. Everyone re-estimates. Repeat until the spread is acceptable, and record the final range and the assumptions.

Three-point estimation

Three-point estimation asks for three values for each task: an optimistic estimate a, a most likely estimate m and a pessimistic estimate b. The weighted mean E = (a + 4m + b) / 6 gives the most likely value four times the weight of the extremes; this is the weighting from PERT. The standard deviation is approximated as SD = (b − a) / 6. The CTFL v4.0 syllabus presents the result as E ± SD.

Two properties make the technique useful. First, pessimistic tails in testing are usually longer than optimistic ones — a build can be weeks late but rarely weeks early — so E is typically higher than m, and the difference is information about risk. Second, the spread b − a shows how uncertain the task is; a task with a wide spread is a candidate for splitting or for early investigation. Treat the SD as an approximation, not a guaranteed probability: it rests on assumptions about the shape of the distribution that real projects do not always follow.

Three-point estimate (PERT weighting)
  a = optimistic     m = most likely     b = pessimistic
  E  = (a + 4m + b) / 6
  SD = (b - a) / 6

Example: design and execute tests for the promotion rules
  a = 6 days    m = 9 days    b = 18 days
  E  = (6 + 4*9 + 18) / 6 = 60 / 6 = 10 days
  SD = (18 - 6) / 6       = 2 days
  Report: about 10 days; E +/- SD = 8-12 days; E +/- 2 SD = 6-14 days

Adding several independent tasks
  E_total  = sum of E
  SD_total = square root of the sum of SD^2   (not the sum of SD)

Try it: Test Estimation Calculator

Work breakdown structure: estimate the parts

A work breakdown structure (WBS) splits the testing into tasks small enough to estimate with confidence — typically no more than a few days each — and estimates each one. It is not a separate estimation technique so much as the structure every other technique works on: three-point estimates or Delphi rounds are far more accurate on ten small tasks than on one large one, and the WBS makes forgotten work visible.

• Test planning and risk analysis; review of requirements and acceptance criteria.
• Test analysis and design per feature, including test data design.
• Environment, integration sandbox and test data setup.
• Automation: new tests and maintenance of existing ones.
• Execution cycles, including exploratory sessions.
• Defect reporting, triage support, re-testing and regression runs after fixes.
• Non-functional testing: performance, security checks, accessibility, localisation.
• Reporting, test completion report and hand-over.

Try it: Regression Scenario Generator

Worked example: estimating a release with three-point and WBS

For example, take release 4.0 ("one-page checkout") of Bustan Market, the fictional Saudi marketplace used in the test plan guide. The QA lead breaks the testing into six tasks, asks the testers who will do the work for three values each, and computes E and SD per task. All numbers are illustrative.

Task (person-days)                                   a     m     b      E     SD
T1 Test analysis and design (CHK-01..05)             3     5     9    5.33   1.00
T2 Environment, payment sandbox, synthetic data      2     3     8    3.67   1.00
T3 Execution cycle 1, incl. exploratory sessions     6     8    14    8.67   1.33
T4 Automated regression: updates and runs            2     3     5    3.17   0.50
T5 Defect re-testing and re-regression               2     4    10    4.67   1.33
T6 Load test, security headers, accessibility pass   2     3     6    3.33   0.67
                                                          ----         -----
Sum of most likely (m)                                     26          E = 28.83
SD_total = sqrt(1.00 + 1.00 + 1.78 + 0.25 + 1.78 + 0.44) = sqrt(6.25) = 2.5

Effort range (E +/- 2 SD):         23.8 - 33.8 person-days
Cross-check (ratio 0.40 x 70 dev days): 28 person-days  -> consistent

Capacity: 3 testers x 0.75 focus factor = 2.25 person-days per working day
Duration:  28.83 / 2.25 = 12.8 working days   (range 10.6 - 15.0)

Assumptions: build 4.0.0-rc delivered on day 1 and passes smoke; payment sandbox
available >= 90% of working hours; promotion rules frozen before design starts;
no more than one fix-and-retest cycle for High-risk features.

Ranges, buffers, assumptions and re-estimation

Notice three things in the example. The sum of the most likely values (26 days) is lower than the three-point total (28.83), because every task has a longer pessimistic tail — reporting "26 days" would have been the optimistic answer presented as the realistic one. The combined SD (2.5) is smaller than the sum of the task SDs (5.83), because independent overruns partly cancel out; if the tasks are not independent — one bad build delays all of them — the real spread is wider. And the ratio-based cross-check lands close to the result, which increases confidence without proving anything.

Communicate the estimate as a range with its assumptions: "24 to 34 person-days, about 11 to 15 working days with three testers, assuming the conditions listed". Put any buffer where it is visible and owned — a named contingency for the go/no-go decision and for a second fix cycle — rather than padding each task silently, which hides the risk and gets spent anyway. Re-estimate when an assumption breaks, when scope changes, and at fixed points such as the end of the first execution cycle, where extrapolation from real progress and defect rates replaces the original guess.

• Estimate the whole of testing, not only execution.
• Let the people who will do the work estimate it; combine views with Delphi or planning poker.
• Give a range and write the assumptions next to it; an estimate without assumptions cannot be re-checked.
• Keep contingency explicit and separate from task estimates.
• Record actuals against estimates each release; that history is what makes ratio-based estimates possible next time.

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• Certified Tester Advanced Level Test Management (CTAL-TM) v3.0ISTQB · 2024ISTQB's advanced syllabus on managing testing: test planning and estimation, risk-based testing, monitoring, metrics and reporting.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• ISO/IEC/IEEE 29119-2:2021 — Software and systems engineering — Software testing — Part 2: Test processesISO/IEC/IEEE · 2021The test process model: organisational, test management and dynamic test processes, with their activities and outcomes.
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009The agile testing quadrants and how testers work inside a delivery team — the basis of "testing at the right layer".