Test Estimation
How long will testing take? How many people do you need? Estimation is a core lead skill — and being able to defend your numbers is as important as getting them right.
What it is
Test estimation is the process of predicting how much effort, time, and resources testing will require. No estimate is exact — the goal is a defensible range with known assumptions, not a precise number.
Good estimates account for: test design, test execution, defect management, test environment setup, reporting, and risk buffers.
Work Breakdown Structure (WBS)
Break the testing work into the smallest estimable tasks, estimate each, then sum them up. The WBS approach makes assumptions visible and allows estimates to be challenged at the task level.
| Task | Hours |
|---|---|
| Review requirements and write test cases | 3 |
| Set up test environment and test data | 2 |
| Execute test cases (happy path) | 1.5 |
| Execute test cases (negative / boundary) | 2 |
| Exploratory testing session | 1.5 |
| Log and manage defects | 1 |
| Retest after fixes | 1.5 |
| Total estimate | 12.5 hours |
Three-point estimation
For each task, estimate three scenarios:
- Optimistic (O) — best case, everything goes smoothly
- Most Likely (M) — realistic expectation
- Pessimistic (P) — worst case, things go wrong
Calculate the weighted average (PERT formula): E = (O + 4M + P) ÷ 6
This gives a more realistic estimate than single-point guessing and surfaces the uncertainty explicitly.
Metrics-based estimation
If you have historical data from similar projects, use it. Common metrics-based approaches:
- Test cases per story point — if you average 3 test cases per story point and a sprint has 40 points, estimate ~120 test cases.
- Time per test case — if each test case takes 30 minutes to design and 15 minutes to execute, multiply by count.
- Defect rate — if historically 20% of test cases find defects and each defect takes 45 minutes to log/retest, factor it in.
Defending your estimate
Estimates will be challenged. Make yours defensible by:
- Showing your WBS — "here are the tasks I’ve included"
- Stating your assumptions — "this assumes the environment is ready and stable"
- Giving a range, not a point — "8–12 hours depending on defect volume"
- Tracking actuals — compare estimates to reality to improve future estimates
Never accept someone else’s estimate for your work. If a PM says "testing should take a day," ask what they’re basing that on. Your WBS is the evidence. A bad estimate accepted silently becomes your problem later.
ISTQB mapping
| Ref | Topic | Level |
|---|---|---|
| CTAL-TM 2.3 | Test estimation — effort, duration, resources | Lead |
| CTAL-TM 2.3 | Estimation techniques: metrics-based, expert judgement, WBS, three-point | Lead |
Practice this technique: Try Test Lead Practice 01 — Test strategy review.
Try It — Three-point PERT estimation
A NZ e-commerce checkout feature needs testing. Three tasks have been broken down. Apply the PERT formula E = (O + 4M + P) ÷ 6 to calculate the weighted estimate for each task, then sum the total.
| Task | Optimistic (O) | Most Likely (M) | Pessimistic (P) | Your E (hrs) |
|---|---|---|---|---|
| Test case design for checkout flow | 2 | 4 | 8 | |
| Execute checkout tests + defect logging | 3 | 5 | 10 | |
| Retest after fixes | 1 | 2 | 6 | |
| Total estimate (sum of E values) | ||||
PERT calculations
| Task | Formula | E (hrs) |
|---|---|---|
| Test case design | (2 + 4×4 + 8) ÷ 6 = (2+16+8) ÷ 6 = 26 ÷ 6 | 4.33 |
| Execute + log defects | (3 + 4×5 + 10) ÷ 6 = (3+20+10) ÷ 6 = 33 ÷ 6 | 5.5 |
| Retest after fixes | (1 + 4×2 + 6) ÷ 6 = (1+8+6) ÷ 6 = 15 ÷ 6 | 2.5 |
| Total estimate | 12.33 hours | |
Answers within ±0.2 of each value are correct — rounding to 1 decimal place is fine in practice. Notice the pessimistic values pull the estimates above the "most likely" — this is intentional. PERT accounts for uncertainty. If everything goes perfectly you finish in 6 hours; if things go wrong you have 12+ hours buffered.