Test Estimation
"How long will it take to test?" is the most common question you'll face. As a Lead, your job isn't to guess — it's to provide a defensible, data-backed range that accounts for the unknowns.
1 The Hook — The $2M "Gut Feel"
A Wellington-based government agency was upgrading their core payroll system. During planning, the Project Manager asked the Test Lead for a timeline. Without a breakdown, the Lead said "testing usually takes about six weeks."
They didn't account for the custom KiwiSaver calculation engine or the complex integration with IRD's legacy systems. Six weeks in, they had only finished 30% of the tests. The project stalled, requiring an emergency budget injection of $2M to cover the delay. The Lead couldn't defend their original number because it was based on gut feel, not structure.
Structured estimation isn't about being perfectly accurate; it's about being defensible when things go wrong.
2 The Rule — The PERT Pattern
Break the work into small tasks (WBS), estimate each with the Three-Point (PERT) formula, and always state your assumptions.
The PERT formula: Estimate = (Optimistic + 4 × Most Likely + Pessimistic) ÷ 6
This weighted average pulls the estimate towards the "likely" but accounts for the "worst case" tail. It’s the industry standard for defending your numbers to skeptical stakeholders.
3 The Analogy — Estimating a House Reno
The Ponsonby Villa Renovation.
If you ask a builder "how long to fix my villa?", they won't just say "three months". They'll count the piles, check the wiring, and measure the floorboards. They know the bathroom might have hidden rot (the Pessimistic case) but the kitchen might be straightforward (the Optimistic case). Test estimation is the same: don't estimate the "project," estimate the piles and the floorboards.
4 Watch Me Do It — KiwiSaver Withdrawal Flow
Scenario: You are the Test Lead for a bank's new "First Home KiwiSaver Withdrawal" feature. It’s complex because it involves three external API checks and a legal document generation step.
- Build the Work Breakdown Structure (WBS) List every task. Don't just say "Execution." Say "API Data Setup," "Negative Scenario Testing," "Legal Doc Verification."
- Gather Three Points for each task Ask your senior tester: "If everything goes perfect, how long? If the API is down half the time, how long? What's most likely?"
-
Apply the Formula
For "API Data Setup":
O = 2h, M = 4h, P = 12h
(2 + (4×4) + 12) / 6 = 30 / 6 = 5 hours
| Task | O | M | P | PERT Estimate |
|---|---|---|---|---|
| Test Design (15 cases) | 4h | 6h | 10h | 6.3h |
| Environment & API Setup | 2h | 4h | 12h | 5.0h |
| Execution & Defect Logging | 8h | 12h | 20h | 12.7h |
| Retesting & Reporting | 2h | 4h | 8h | 4.3h |
| Total | 16h | 26h | 50h | 28.3 hours |
Notice the "Gut Feel" might have been 26 hours (the most likely sum). The PERT formula added 2.3 hours of "risk buffer" based on the pessimistic tail. That's your safety margin.
5 Decision Tool — Which Method When?
📋 Use WBS + PERT when...
- The project is high-risk or high-budget
- You have a detailed requirement or design
- You need to defend your numbers to a PM
- The team is new to the feature area
⏱ Use Metrics-Based when...
- You have 3+ months of historical data
- The work is highly repetitive (e.g. BAU)
- You need a "top-down" estimate in 5 mins
- The scope is defined by Story Points
6 Common Mistakes
🚫 "I can't estimate without a full spec"
I used to think: I'll wait for the final requirements.
Actually: In Agile NZ, you rarely get a final spec. Estimate based on what you know, list your assumptions (e.g., "Assumes API 2.0 is used"), and give a wide range. An early range is better than a late surprise.
🚫 Accepting a "mandated" deadline
I used to think: The PM said it must be done by Friday, so I'll just try harder.
Actually: If your WBS says 40 hours and you have 20 hours left, you cannot "try harder" into success. Use the WBS to negotiate scope: "Which 20 hours of testing shall we de-prioritise to hit Friday?"
7 Now You Try — The PERT Calculator
You're estimating a Regression Suite for a mobile banking app. Apply the PERT formula to these tasks.
| Task | O | M | P | Your E (hrs) |
|---|---|---|---|---|
| Prep Test Environment | 1 | 2 | 6 | |
| Execute Core Flow (10 cases) | 5 | 8 | 15 |
Solution:
- Task 1: (1 + (4×2) + 6) / 6 = 15 / 6 = 2.5h
- Task 2: (5 + (4×8) + 15) / 6 = 52 / 6 = 8.7h
If your total is ~11.2 hours, you're ready to lead a planning session.
8 Self-Check
Q1. Why does PERT use a divisor of 6?
Because it's a weighted average. You have 1 part Optimistic, 1 part Pessimistic, and 4 parts Most Likely. 1 + 1 + 4 = 6. This gives the "Likely" scenario more weight while still factoring in the extremes.
Q2. A PM says "Just give me a single number, not a range." What do you do?
Provide the PERT estimate (the single weighted number) but attach your WBS and a list of assumptions. Say: "The number is 28 hours, provided the environment is stable and the requirements don't change."
9 Interview Prep
"How do you handle a situation where your estimate is rejected by the business?"
Answer: "I walk them through my Work Breakdown Structure. I ask which specific tasks or risks they would like me to remove to meet their target. This shifts the conversation from 'arbitrary time' to 'quality trade-offs'. If we cut the estimate by 50%, we are cutting the coverage by 50% — and I make sure that risk is documented and signed off."
10 Next Step
Estimation is half the battle. The other half is tracking. Go to your first practice session to build a full estimation sheet.