Unrealistic test estimates cause project failures — either by over-promising or by being ignored
A tester who estimates "two weeks for testing" without a basis for that number will either be held to it when it is wrong, or dismissed as someone who does not understand the project. Either outcome damages trust and quality.
Test estimation is the process of approximating the effort, time, and resources needed for testing activities. Good estimates are transparent, justified, and continuously revised as more information becomes available.
// example: netflix — estimating a major platform overhaul
Test Estimation Techniques — CTFL 4.0.1
Expert-based estimation
Relies on the experience and judgement of skilled testers or managers. Techniques include:
- Wideband Delphi — multiple experts estimate independently, discuss discrepancies, and converge on a consensus
- Planning poker — common in Agile; team members select estimation cards simultaneously to avoid anchoring bias
Metrics-based estimation
Uses historical data from previous projects to derive estimates. Approaches include:
- Extrapolation — if previous similar feature took X hours per test case, estimate new feature by scaling
- Test point analysis — assigns complexity weights to test conditions and converts to effort
Three-point estimation
Produces a more realistic estimate by combining three scenarios:
- O (Optimistic) — best case if everything goes smoothly
- M (Most likely) — the expected case based on experience
- P (Pessimistic) — worst case with realistic problems
Formula (PERT): Expected Estimate = (O + 4M + P) ÷ 6
// tip: Exam Tip: Know the three-point estimation formula: (Optimistic + 4 × Most Likely + Pessimistic) ÷ 6. The exam may give you three values and ask for the PERT estimate. Also remember that estimates should always be presented as ranges with stated assumptions — not as single definitive numbers.
Three-Point Estimation — Worked Example
Scenario: Estimate the testing effort for a new user authentication module.
| Scenario | Assumption | Estimate |
|---|---|---|
| Optimistic (O) | Requirements are clear, no environment issues, 1 experienced tester | 40 hours |
| Most Likely (M) | Some requirement clarifications needed, minor environment delays | 70 hours |
| Pessimistic (P) | Requirements change mid-testing, environment instability, defect rate is high | 130 hours |
PERT Calculation:
Expected = (O + 4M + P) ÷ 6 = (40 + 4 × 70 + 130) ÷ 6 = (40 + 280 + 130) ÷ 6 = 450 ÷ 6 = 75 hours
Present as a range: 65–85 hours, with stated assumptions. The PERT estimate weights the most likely scenario four times heavier than the extremes, producing a more realistic result than a simple average.
Three-Point (PERT)
Basis
Optimistic, Most Likely, Pessimistic scenarios
Best for
High-uncertainty tasks; when range is more useful than point estimate
// Pros
- ✓
Accounts for uncertainty
- ✓
Produces realistic range
- ✓
Weights most likely scenario heavily
// Cons
- ✗
Requires honest pessimistic estimation
- ✗
Still subjective
- ✗
Formula may feel arbitrary to stakeholders
// PERT Calculator
Formula: (O + 4M + P) ÷ 6
Optimistic (O)
Most Likely (M)
Pessimistic (P)
// Result
75 hours
Present as range: 65–85 hours
// Example
O=40h, M=70h, P=130h → (40 + 4×70 + 130) ÷ 6 = 75h (present as 65–85h range)
// Exam tip
Estimates should ALWAYS be presented as ranges with stated assumptions — not single numbers. The exam will test whether you understand that estimates are approximations, not commitments.
Test Estimation Techniques Compared
| Technique | Basis | Best Used When | Limitation |
|---|---|---|---|
| Expert judgement | Tester experience and intuition | Early in project with little data; experienced team | Subjective; anchoring bias risk |
| Wideband Delphi | Multiple expert consensus | Complex or unfamiliar systems; multiple stakeholders | Time-consuming; requires expert availability |
| Planning poker | Team consensus with cards | Agile sprints; team has shared context | Only works with shared understanding of scope |
| Metrics-based | Historical project data | Repeat project type; historical data exists | Requires comparable historical data |
| Three-point (PERT) | Optimistic, likely, pessimistic scenarios | High-uncertainty tasks; when range is more useful than a point | Requires honest pessimistic estimation |
// warning: Exam Trap: "An estimate is a commitment." This is false. An estimate is an approximation based on current knowledge and stated assumptions. As the project progresses and more information becomes available, estimates should be revised. Presenting an estimate as a fixed commitment without stating assumptions creates unrealistic expectations and damages trust when reality differs.
Exam Practice Questions
// ctfl 4.0.1 style — select an answer to reveal explanation