Test Estimation
Every project starts with "how long will testing take?" Learn three methods to answer with confidence, not guesswork.
1 The Hook — Why This Matters
In 2021, a Wellington-based insurance software company signed off on a six-week project to build a new claims module. The project manager asked the test lead for an estimate. The test lead glanced at the requirements and said, "About three weeks." No method. No buffer. Just gut feel.
The module arrived for testing in week five. The test team immediately discovered unstable test data, three integrations that weren't ready, and requirements that had changed after the initial estimate. The "three weeks" became seven. The project shipped late, the client missed their regulatory filing deadline, and the test lead's credibility was shattered.
The real tragedy? A proper Three-Point estimate would have predicted 37 ± 5 days from the start. The team could have flagged the risk early, negotiated scope, or added resource. Instead, one unmethodical guess cost trust, money, and a client relationship.
Senior engineer insight
The shift that changed how I think about estimation happened when I stopped treating it as a forecasting problem and started treating it as a communication problem. Your stakeholders do not need the exact number — they need to know what would have to be true for the number to hold. Once I started presenting estimates as "36 days assuming stable test data, 46 days if we hit the environment refresh issues we saw on the tax module," the conversation completely changed: instead of defending a number, I was managing risk together with the PM.
The most common mistake Test Lead testers make with estimation is conflating the act of producing a number with the act of communicating the assumptions behind it — then wondering why stakeholders treat the estimate as a fixed commitment.
From the field
On a Wellington public sector programme — a large Revenue NZ-adjacent modernisation — the test team inherited a spreadsheet estimate that had been built by the BA team using pure analogous reasoning: "the last module took eight weeks, so this one will too." What the BA team didn't know was that the historical velocity data behind that eight-week figure included a three-person team with a pre-built test harness. This team had two testers and no harness. When we ran a Three-Point session, the pessimistic case came in at nineteen weeks. The PM was furious, until we walked him through the velocity mismatch — and he agreed to a phased approach. The lesson that generalises: analogous estimation is only valid when the historical baseline and the current team context are genuinely comparable; always sanity-check the source data before you borrow the number.
2 The Rule — The One-Sentence Version
Estimate with three methods, never one point, and always leave a traceable buffer.
A single estimate is a guess. A range built from multiple methods is a professional opinion. When you can explain how you arrived at a number, stakeholders can argue with the method instead of arguing with you.
3 The Analogy — Think Of It Like...
Building a house and getting three quotes.
You ask an experienced builder (Expert Judgment), compare to the house next door that just finished (Analogous), and get a best-case / worst-case quote from the same builder (Three-Point). If all three cluster around twelve weeks, you plan for twelve. If they spread from eight to twenty, you know there's uncertainty and you budget a contingency. You would never build a house on a single verbal guess. Don't run a test project on one either.
4 Watch Me Do It — Step by Step
Here is a real NZ example: estimating testing for a new insurance claims module. Follow these steps every time you are asked "how long will testing take?"
- Apply Expert Judgment Ask the person who will actually do the work. In this case, the senior tester estimates 40 person-days based on complexity, integration points, and their experience with the existing platform. Write the number down but do not stop here.
- Apply Analogous Estimation Find a similar module tested recently. The policy-renewal module took 35 person-days and had comparable scope. Adjust up or down for differences (this module has one extra integration, so adjust to ~38). Record the adjusted historical figure.
-
Apply Three-Point Estimation
Ask the same expert for three numbers: optimistic (O), most-likely (M), and pessimistic (P).
- O = 25 days (everything works first time, no defects)
- M = 35 days (normal defect rate, minor environment issues)
- P = 55 days (major integration defects, data issues, retest cycles)
E = (O + 4M + P) / 6 = (25 + 140 + 55) / 6 = 36.7 days
Calculate standard deviation:SD = (P − O) / 6 = (55 − 25) / 6 = 5.0 days
- Triangulate the three methods Expert: 40d. Analogous: ~38d. Three-Point: 36.7 ± 5.0d. All three cluster in the high-thirties. Present the estimate as 37 ± 5 person-days with 68% confidence, or 37 ± 10 days with 95% confidence.
- Add a buffer for unknowns Add 20–30% for retest cycles, environment instability, and late requirement changes. On 37 days, a 25% buffer is ~9 days. Final estimate: 46 person-days with documented assumptions.
- Track actuals and refine Log time spent against each task. If the module actually took 42 days, your Three-Point model was accurate and your buffer was well-judged. Update your historical data for next time.
| Method | Input / Calculation | Result |
|---|---|---|
| Expert Judgment | Senior tester assessment | 40 person-days |
| Analogous | Similar module (35d) + 1 extra integration | ~38 person-days |
| Three-Point | O=25, M=35, P=55 | E = 36.7d, SD = 5.0d |
| Range (68%) | 37 ± 5 days | 32 – 42 days |
| With 25% buffer | 37 + 9 days | 46 person-days |
5 When to Use It / When NOT to Use It
✅ Use estimation when...
- You need to plan sprints, releases, or resource allocation
- Stakeholders need a date range for regulatory or commercial deadlines
- You are bidding for fixed-price work or writing Statements of Work
- You want to identify and communicate risk through range width
- The team is new and you need to calibrate their velocity
❌ Don't rely on formal estimation when...
- The task is genuinely trivial (< 1 hour) and estimation overhead exceeds value
- The deadline is fixed and scope is flexible (use story points instead)
- Estimates have been weaponised as commitments or performance targets
- You have no time to decompose the work into small tasks
- The estimate is demanded before requirements are stable enough to assess
Before you estimate, ask:
- Are requirements stable enough that you can decompose the work into tasks?
- Do you have historical velocity data from this team, or is this a new domain for them?
- Are estimates being weaponised as commitments or performance targets?
- Will scope be locked or flexible once you commit to the estimate?
6 Common Mistakes — Don't Do This
🚫 Padding every estimate
I used to think: If I add 50% to every task, we'll never be late.
Actually: Systematic padding destroys credibility. Stakeholders learn to halve your estimates, which means your genuine risks get cut too. Use a traceable buffer based on known risk factors (retest cycles, environment instability) and document the justification. A transparent 25% buffer is defensible. A hidden 50% buffer is not.
🚫 One-point estimates with no buffer
I used to think: "It'll take three weeks" is a clear answer.
Actually: A single number implies certainty that does not exist. Always provide a range with confidence. "37 ± 5 days (68% confidence)" tells stakeholders there is uncertainty and gives them the information to decide whether to absorb risk or add resource. One-point estimates become self-fulfilling disasters.
🚫 Ignoring retest and regression time
I used to think: My estimate only needs to cover the first execution of each test.
Actually: In mature systems, retest and regression often consume 30–50% of total test effort. A defect found in sprint three may require full regression of sprints one and two. If your estimate omits retest cycles, you are guaranteeing an overrun before testing even begins.
When this technique fails
Estimation fails when it becomes a fixed commitment without room for learning. If estimates are weaponised to hold testers accountable for unknowns, they will be padded or sandbagged. It also fails when retest and regression effort is ignored: the estimate covers first execution, but not the 30% of time spent retesting. Finally, estimates made before requirements stabilise are useless: if scope creeps, the estimate becomes instantly irrelevant.
7 Now You Try — Interview Warm-Up
Scenario: You are estimating testing for a new NZ bank API integration. The senior tester thinks it will take 20 days if everything goes well, 32 days normally, and 50 days if the upstream API has breaking changes.
Calculate the Three-Point expected value and standard deviation. Then add a 20% buffer. What is your final estimate?
Three-Point calculation:
| Step | Calculation | Result |
|---|---|---|
| Optimistic (O) | Given | 20 days |
| Most-likely (M) | Given | 32 days |
| Pessimistic (P) | Given | 50 days |
| Expected value | (20 + 4×32 + 50) / 6 | 33 days |
| Standard deviation | (50 − 20) / 6 | 5 days |
| 20% buffer | 33 × 0.20 | 6.6 days |
| Final estimate | 33 + 6.6, rounded | 40 person-days |
Tip: Present this as "33 ± 5 days expected, 40 days with contingency." The range communicates uncertainty; the buffered number protects the project.
Why teams fail here
- Estimates are built at the feature level, not the task level — tasks over two days hide complexity that causes overruns when the work actually starts.
- Historical velocity data from a different team composition is used without adjustment — a three-person team's baseline is not transferable to a two-person team, even on the same codebase.
- Retest and regression effort is omitted entirely from the initial estimate, then added as an unplanned cost after the first major defect cycle hits in week three.
- The documented buffer is stripped out by the PM during planning without a corresponding reduction in scope, leaving the team exposed when known risks materialise.
Key takeaway
An estimate without its assumptions is just a number someone will use against you — always deliver the range, the method, and the conditions under which the number holds.
Enterprise reality
Programme-scale estimation with multiple workstreams and procurement constraints
- Estimates feed procurement contracts — underestimating testing effort creates legal exposure when a Statement of Work commits to a test-complete date that the team cannot achieve.
- Contingency is set by the programme board, not the test lead — your Three-Point range is an input to a governance decision, not a number you own; expect it to be negotiated down and document your objections formally.
- Estimates are baselined and tracked against actuals for governance reporting — every material deviation triggers a change request, so the original estimate must be defensible months after it was produced.
- Historical data from prior programme phases is used instead of gut feel — on multi-year programmes, velocity from Phase 1 is the authoritative source; validate that team composition and tooling are comparable before borrowing the baseline.
8 Self-Check — Can You Actually Do This?
Click each question to reveal the answer. If you got all three, you're ready to practice.
Q1. Why is Three-Point estimation more reliable than Expert Judgment alone?
Three-Point estimation forces the expert to consider best-case, most-likely, and worst-case scenarios, which surfaces hidden risks. It also produces a standard deviation, giving stakeholders a quantified range instead of a single guess. When combined with Expert Judgment and Analogous estimation, you get triangulation that exposes optimism bias.
Q2. What are the six factors that should influence a test estimate?
Complexity of the feature, requirements stability, team experience, tool maturity, test data availability, and environment stability. In NZ contexts, also consider defect density history from previous releases and any regulatory deadlines that may compress the schedule.
Q3. When should you use story points instead of person-days?
Use story points in Agile teams where scope is flexible and the goal is relative sizing across a backlog, not calendar prediction. Use person-days (or hours) when you need to communicate with external stakeholders, meet fixed regulatory deadlines, or write Statements of Work with contractual dates.
9 Interview Prep — What They'll Ask
These are real questions from Test Lead interviews in the NZ market. Click to reveal a strong answer.
Q1. How do you estimate when there's no historical data?
Use Three-Point estimation with a deliberately wide range to account for unknowns. Decompose the work into the smallest possible tasks—each under two days—because small tasks are easier to estimate than large ones. Use industry benchmarks (e.g., defect density by team size) as a starting point. Most importantly, track actuals from day one and refine your model after the first sprint or milestone.
Q2. A project manager demands a single date, not a range. How do you handle it?
I explain that a single date is a commitment, not an estimate, and commitments require a corresponding commitment to scope and resources. I offer a high-confidence date with a documented buffer and a lower-confidence date with less buffer, making the trade-off visible. If they still insist on one date, I add a contingency buffer of at least 20% and document the assumptions so that when reality diverges, we can renegotiate scope instead of blaming the test team.
Q3. How do you prevent estimates from becoming self-fulfilling overruns?
By decomposing into small, trackable tasks and measuring velocity from the first week. If the team is completing 70% of planned tasks per sprint, I adjust future estimates downward rather than hoping for a miraculous speed-up. I also separate "estimate" from "commitment" in written form so stakeholders understand that an estimate is a probability distribution, not a promise.
Q4. What estimation factors are unique to testing (as opposed to development)?
Test data provisioning time, environment stability and refresh cycles, retest and regression effort after defect fixes, tool licence or configuration overhead, and the time required to analyse and report defects. Development estimates often ignore these because they are downstream of coding; a Test Lead must add them explicitly.