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.
1 The Hook
A Wellington fintech needs sign-off on a new payments release. The project manager corners the test lead in a stand-up: "Testing's quick, right? Call it two days." The lead, not wanting to look slow, nods. Two days goes in the plan.
Day three arrives and testing is nowhere near done. The environment was unstable for half of day one, the build had to be re-tested twice after fixes, and nobody had counted the regression suite. The release slips, and because the lead "owned" the estimate, the lead owns the blame — for a number someone else pulled out of the air.
The trap was accepting a figure with no working behind it. An estimate is not a guess you agree to under social pressure; it is a calculation you can show. Had the lead broken the work into tasks and put a number on each, "two days" would have been visibly wrong before it was ever written down — and the conversation would have been about evidence, not optimism.
Test estimation is the skill of producing a defensible range for testing effort by breaking work into tasks, pricing each one, and stating the assumptions that hold the number together — use it any time you are being asked to commit to a date, headcount, or sprint allocation. Apply it when scope is defined and pressure is real; skip it for micro-releases or tiny features where a quick checklist serves better. The most common mistake is accepting a figure someone else invented — once you nod at that number in a stand-up, you own it, including the overrun.
From the field
A NZ bank modernisation asked three senior testers to estimate a core module independently. Estimates came back 3 weeks, 6 weeks, and 11 weeks for the same scope. A Three-Point Estimation session uncovered the divergence: one tester included data migration, one assumed automation existed, one costed environment setup. Estimation disagreements almost always expose unstated assumptions — the right response is to surface them, not split the difference.
After twenty years of test leads being blamed for overruns, I can tell you the number is almost never the problem — the missing line items are. Every junior I've mentored estimates execution hours correctly. What they forget is the archaeology: reading undocumented code to understand what actually needs testing, chasing developers for acceptance criteria that should have existed before sprint start, waiting two hours for an environment reset because a deployment locked the database. On Revenue NZ and Benefits NZ projects I've seen environment overhead consume 35% of the total testing time. It never appears in the WBS because nobody wants to write "we don't trust our own infrastructure." Write it anyway. Call it "environment tax." It is the most defensible line you will ever put in an estimate.
2 The Rule
An estimate is only as good as the working behind it — break the testing into tasks, put a number on each (ideally a range, not a point), state your assumptions, and never accept someone else's figure for your own work.
3 The Analogy
Getting a builder's quote for a deck.
A trustworthy builder quoting a deck in Tauranga does not just say "about five grand." They itemise: timber, fixings, labour days, council consent, a contingency for rotten piles they might find once they lift the old boards. You can read the quote, challenge a line, and see exactly what assumption the price rests on. The builder who says "five grand, trust me" is the one who hits you with a variation halfway through.
Test estimation is writing the itemised quote, not the back-of-the-napkin number. The work breakdown is your line items, the three-point range is your contingency for the rotten piles you cannot see yet, and the stated assumptions are the fine print that protects you when the ground turns out to be soft.
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.
4 Industry Reality
- Requirements are never complete when you estimate. Most NZ teams estimate from JIRA tickets that say "Add payment gateway" with no acceptance criteria. Senior testers build buffers for the discovery work — reading code, interviewing devs, probing edge cases — because that work always exists even when it is not named.
- Estimates get accepted silently and then locked in. A number thrown out in a planning call becomes a fixed commitment by the next stand-up. If you do not push back in the moment with your WBS, you will spend the sprint defending a figure you never agreed to. The Wellington fintech scenario is not a cautionary tale — it is Tuesday.
- Legacy systems destroy estimates. On legacy banking or government systems (think older Benefits NZ or Revenue NZ platforms), environment flakiness, deployment queues, and opaque data states can consume 30–50% of your testing time. Experienced testers on legacy projects add an explicit "environment tax" line to their WBS.
- Three-point estimation rarely survives contact with a PM. In practice, a single PERT number gets presented to stakeholders, who then negotiate it down anyway. The real value of three-point estimation is internal — it forces you to think about the worst case and surfaces where the uncertainty actually lives, even if only the middle number leaves your mouth.
- Historical data is almost never clean. Metrics-based estimation looks elegant in theory. In practice NZ teams rarely track test case counts, execution times, or defect rates consistently. You often have to build your own tracking from scratch (a simple spreadsheet) before the data becomes trustworthy enough to use.
5 When to Use It — and When Not To
✓ Use it when
- You are being asked to commit to a date or headcount for a release — you need a defensible number, not a guess.
- The project is complex (multiple integrations, payment flows, regulatory requirements) and stakeholders have unrealistic expectations about testing speed.
- You have historical data from similar previous projects and can apply metrics-based estimation with real numbers behind it.
- You are writing a test plan or test strategy that needs a resourcing section — WBS estimation gives you the staffing calculation.
- Sprint planning requires you to size testing tasks alongside development — three-point estimation fits naturally into story-point conversations.
✗ Skip it when
- The feature is tiny and well-understood — a one-page content update does not need a WBS; a quick gut check and a note in your test plan is enough.
- You are in a pure exploratory testing session — time-boxing a charter is more useful than estimating test cases you have not designed yet.
- Requirements are so volatile that any estimate will be obsolete within a day; spend the effort on a risk register instead and revisit estimation when scope stabilises.
- The team is running continuous delivery with micro-releases — formal estimation overhead does not fit; defect lead-time metrics are more useful signals.
- You are doing a quick smoke test after a hotfix — the scope is fixed and obvious; a checklist beats a WBS every time.
Context guide
How the right level of test estimation effort changes based on project context.
| Context | Priority | Why |
|---|---|---|
| Revenue NZ or Benefits NZ gateway programme — multi-team, fixed delivery window, OIA-auditable records | Essential | Government gateway reviews require a formal test effort estimate in the submission. An undocumented number will not satisfy the review board and puts your release window at risk. |
| Harbour Bank or Pacific Bank core banking release — payments, KiwiSaver, CCCFA-regulated features | Essential | Regulatory risk means a test underrun is a compliance failure, not just a quality gap. The WBS becomes your evidence that coverage was planned and deliberate. |
| TransitNZ or CoverNZ digital service — moderate complexity, Privacy Act 2020 obligations, public-facing | High | Sprint-level WBS and stated assumptions protect the team when scope creeps mid-sprint. A three-point estimate on uncertain stories keeps the release date credible rather than aspirational. |
| Pacific Air or Spark agile squad — continuous delivery, two-week sprints, mature regression automation | Medium | Relative sizing at sprint planning is usually sufficient. Reach for explicit WBS estimation only on large stories or when a feature touches payment or safety-critical paths outside the normal regression set. |
| HealthNZ patient-records integration — legacy HL7/FHIR systems, high environment instability | Essential | Legacy clinical systems introduce environment uncertainty that is invisible until it hits. An explicit "environment tax" WBS line (often 30–40% of total effort) is the only way to avoid a systematic overrun on every release. |
| Small NZ SaaS startup — single tester, weekly deploys, no formal planning cadence | Low | A lightweight checklist and rough hour estimate per story is proportionate. Formal WBS overhead exceeds the value at this scale — save it for when a release has real stakeholder scrutiny or an integration with a regulated partner. |
Trade-offs
What you gain and what you give up when you choose Test Estimation.
| Advantage | Disadvantage | Use instead when… |
|---|---|---|
| Produces a defensible, evidence-based number — every hour is traced to a task, so challenges must be about the work rather than the total. | Takes real time to produce well — a thorough WBS for a complex feature can take 30–90 minutes, which is wasted if requirements change the next day. | Requirements are highly volatile; use a risk register and revisit estimation once scope stabilises. |
| Makes hidden work visible — environment setup, defect retesting, and reporting are priced explicitly rather than absorbed silently into execution time. | Formal WBS overhead can outweigh benefit on small features — estimating a one-page content fix as thoroughly as a payments integration is disproportionate. | The feature is well-understood and low-risk; a brief checklist and rough hour gut-check is proportionate. |
| Surfaces assumption mismatches early — three different testers estimating the same scope will quickly reveal diverging views on scope, automation coverage, and environment reliability. | Precision is false comfort — even a carefully built WBS is a prediction; actual defect volumes and environment behaviour can still blow the estimate without anyone having done anything wrong. | Teams running continuous delivery with micro-releases; use defect lead-time and escaped-defect rate as the planning signal instead. |
| Satisfies audit and gateway requirements — Revenue NZ, Benefits NZ, and Harbour Bank regulatory submissions explicitly require a documented test effort estimate; an undocumented number will fail review. | Metrics-based estimation requires clean historical data — most NZ teams do not track test case counts, execution times, or defect rates consistently, so the method looks rigorous but may rest on unreliable inputs. | You are in a time-boxed exploratory session with no defined scope; a session charter with a fixed duration is more useful than estimating test cases you have not designed yet. |
Enterprise reality
How test estimation changes at 200–300-developer scale in NZ enterprise
- At Revenue NZ and Benefits NZ — organisations running programmes with 50+ active test engineers — estimation is governed, not improvised. A Centre of Excellence publishes approved techniques (WBS + three-point), mandates that estimates are stored in the test management tool (typically Xray or Azure Test Plans), and requires a test lead sign-off before any figure enters a gateway submission. The individual "quick WBS on the spot" habit still matters, but it now feeds a formal artefact that auditors can trace to a release.
- Compliance obligations change the cost model. On programmes touching the Privacy Act 2020 or the NZ Information Security Manual (NZISM), the WBS must include explicit line items for security testing, privacy-impact validation, and accessibility (WCAG 2.1 AA). Omitting these is not a planning oversight — it is a compliance gap that can delay a gateway release for weeks. PCI DSS-in-scope features (Harbour Bank, Coastal Bank, KiwiFirst Bank) add penetration-testing windows that are booked weeks in advance and cannot simply be squeezed if the estimate was wrong.
- Tooling makes estimation data-driven at volume. Teams at TeleNZ or TechServNZ running thousands of automated regression tests use Azure DevOps pipeline metrics to generate a baseline: average execution time per test run, flaky-test overhead, and environment provisioning lead time are all tracked and fed back into the next estimation cycle. The "track your actuals in a spreadsheet" advice for small teams becomes a dashboard in Jira or ADO maintained by the test practice, not individual testers.
- Cross-squad coordination is the estimation failure mode that small-team experience does not prepare you for. When a feature spans 10+ squads — common on Pacific Air's loyalty platform or Pacific Bank's core-banking modernisation — the critical path is almost never the testing itself; it is the integration dependencies between squads. A squad that underestimates its testing by two days does not just slip its own delivery: it can delay the integration test window for every squad downstream. Senior test leads on these programmes estimate integration testing separately from feature testing and build explicit dependency buffers for squad handoffs.
◆ What I would do
Professional judgement — when to reach for test estimation, when to skip it, and what to watch for.
The bottom line: The value of an estimate is not its precision — it is the conversation the working forces. A WBS that is wrong in the details is still more useful than a guess that was never challenged, because it gives everyone a shared list of what testing actually consists of.
6 Best Practices
- ✓ Always give a range, never a point. "10–14 hours" is more honest than "12 hours" and opens a conversation about what drives the high end rather than turning every overrun into a personal failure.
- ✓ Write your assumptions down and share them explicitly. "This estimate assumes a stable test environment from day one and a clean build with no blocking defects" — put it in writing. The moment an assumption is violated, your estimate changes and you have the evidence to say so.
- ✓ Build an explicit "defect management" line in every WBS. Most junior testers forget to cost the time to log, triage, retest, and close defects. On a feature with moderate complexity this can add 20–30% to the total.
- ✓ Add a contingency line for environment and tooling risk. Especially on projects involving cloud environments, payment gateways, or legacy NZ government systems where deployment windows are narrow and resets take hours.
- ✓ Track your actuals every sprint. A simple spreadsheet comparing estimated vs. actual hours per task is worth more than any estimation technique. After three sprints you have real calibration data specific to your team and codebase.
- ✓ Never accept someone else's estimate silently. If a PM, scrum master, or developer puts a number on your testing, treat it as a starting point for a conversation, not a commitment. Ask: "What are you basing that on?" Then put your WBS on the table.
- ✓ Re-estimate when scope changes. A change to acceptance criteria mid-sprint or a late-breaking integration requirement is a formal trigger to revise your estimate — not something to absorb quietly and overrun on.
- ✓ Use three-point estimation for high-uncertainty tasks, WBS for the overall picture. They are complementary: WBS gives you the task list; three-point gives each uncertain task a more realistic hour figure than a single guess would.
- ✓ Involve developers when estimating complex features. They often know where the technical risk is (e.g., "the payment retry logic is new and untested") — that knowledge should feed directly into your pessimistic estimate.
- ✓ Present estimates at the right altitude for the audience. A test lead summary for an executive ("approximately two sprints of one tester") is different from the WBS you share with the project manager — know which view your audience needs.
7 Common Misconceptions
❌ Myth: A good tester should be able to give a precise number — ranges just look like uncertainty or lack of confidence.
Reality: Ranges are not a sign of weakness — they are a sign of honesty. A single point estimate implies a precision that does not exist in software testing. When experienced testers give ranges they are communicating exactly how much uncertainty exists and where it comes from (usually defect volume and environment stability). Stakeholders who push back on ranges are asking you to lie; the professional response is to explain what the assumptions would need to be to reach the low end.
❌ Myth: Estimation is only needed for big, formal projects — agile teams just pull testing tasks into the sprint and adjust as they go.
Reality: Agile teams estimate testing constantly — they just call it "sizing" or "pointing." When you say a story is 3 points and testing is included, you are making an estimation decision. The difference is that without an explicit test estimation step, testing almost always gets squeezed because the development sizing dominates. Skilled testers in agile environments make the testing effort visible in sprint planning, even if they use story points rather than hours.
❌ Myth: The PERT formula is overly academic — in practice teams just use their gut feel and it works out.
Reality: Gut feel anchors on the most likely case and systematically underestimates tail risk. The reason the PERT formula weights Most Likely at 4× is precisely to keep estimates grounded in reality while still pulling the number toward the pessimistic tail when things can go wrong. The technique is most valuable on uncertain tasks where the pessimistic scenario is genuinely different from the most likely one — like testing a payment integration for the first time, or running regression on a system that has never had automated coverage.
8 Now You Try
Three graded exercises — spot, fix, then build. Write your answer, run it for AI feedback, then compare to the model answer.
You estimated 14 hours to test a new Revenue NZ myIR payment screen. A project manager says, "That's too much — make it a day." Write the three things you would put on the table to defend your number, and explain why giving a single point figure of "8 hours" would be a weaker answer than a range.
Show model answer
Three things to put on the table: 1. The work breakdown structure (WBS) — the itemised list of tasks (test design, environment setup, execution, defect logging, retest, reporting) with hours against each. This is the evidence that the 14 hours is built from real work, not a feeling. 2. The assumptions — e.g. "this assumes the test environment is available and stable from day one, and that the build is delivered defect-light." If the PM wants a day, ask which assumption they want to change. 3. A range, not a point — "12 to 16 hours depending on defect volume." This signals honestly where the uncertainty is. Why a range beats a single "8 hours": a single point implies a precision you do not have and sets you up to be "wrong" the moment reality differs by an hour. A range communicates the uncertainty truthfully, invites a conversation about what drives the high end (usually defect volume and environment stability), and protects you because you committed to a band, not a false certainty.
A junior estimated a task with Optimistic = 2 h, Most Likely = 6 h, Pessimistic = 10 h and wrote: "PERT estimate = (2 + 6 + 10) ÷ 3 = 6 hours." The formula is wrong. Correct it, show the right calculation, and explain what the mistake does to the estimate.
PERT estimate = (O + M + P) ÷ 3 = (2 + 6 + 10) ÷ 3 = 6 hours
Correct it:
Show model answer
Correct PERT formula: E = (O + 4M + P) ÷ 6 Correct calculation: (2 + 4×6 + 10) ÷ 6 = (2 + 24 + 10) ÷ 6 = 36 ÷ 6 = 6 hours In this particular case the answer happens to be the same (6 hours) because the values are symmetric, but the working is wrong and would give a different answer for almost any other input. What the mistake changes: a plain average (O + M + P) ÷ 3 treats best case, likely case and worst case as equally probable. PERT does not — it weights the Most Likely value four times as heavily, which is the whole point of the technique. With skewed inputs (say O=2, M=3, P=20) the plain average gives 8.3 h but PERT gives (2 + 12 + 20) ÷ 6 = 5.7 h. Using the wrong formula on skewed tasks systematically over- or under-estimates and discards PERT's main benefit: anchoring on the realistic case while still accounting for the tail risk.
A NZ council is releasing an online dog-registration renewal form (payment, owner details, multiple dogs per household). Build a work breakdown structure estimate: list at least six testing tasks, put an hour figure on each, give a total, and state two assumptions your estimate depends on.
Show model answer
A defensible WBS for the dog-registration renewal form: - Review requirements and acceptance criteria, write test cases — 4 h - Set up test environment and seed test data (owners, multiple dogs, payment accounts) — 2 h - Execute happy-path tests (single dog renewal, payment success) — 2 h - Execute negative / boundary tests (invalid card, multiple dogs, missing fields) — 3 h - Exploratory session on the payment and multi-dog logic — 2 h - Log and manage defects + retest after fixes — 3 h - Regression check on the existing registration flow — 2 h - Test report and sign-off — 1 h Total estimate: ~19 hours (a sensible band would be 17–22 h) Two assumptions the estimate depends on: 1. The test environment and payment sandbox are available and stable from day one. 2. The build is delivered defect-light — heavy defect volume on first execution would push the retest and defect-management line well past 3 hours, which is why the upper end of the range exists. A senior would note the multi-dog-per-household rule is the riskiest area (combinations of dogs, part-payments, removals) and would weight exploratory and negative testing there, and would give the total as a range with the defect-volume assumption called out explicitly.
Self-Check
Click each question to reveal the answer.
Why teams fail here
- Estimates exclude non-test activities: environment setup, test data creation, defect retesting, and stakeholder sign-off
- Historical velocity data is not used — each project starts from scratch with gut-feel estimates
- Estimates are given as single-point numbers with no risk buffer or uncertainty range
- Scope changes during the project but the original estimate is never updated, making tracking meaningless
How this has changed
The field moved. Here is how Test Estimation evolved from its origins to current practice.
Test estimation is informal — experienced testers give gut-feel estimates, managers halve them. No systematic techniques exist. Projects consistently underestimate testing effort and testing is compressed when delivery slips.
Function point-based estimation and use-case points adapted for test effort estimation. ISTQB and IEEE provide estimation frameworks. Formal estimation begins entering test management as a discipline, but application is inconsistent.
Agile velocity and story points replace formal estimation for many teams. Relative estimation (comparing stories) proves more accurate than absolute hour estimates for sprint-level planning. Testing effort is estimated as a proportion of development effort rather than independently.
Evidence-based test estimation matures — teams use historical data (defect rates, regression times, exploration session counts) to ground estimates. The shift from "how long will testing take?" to "what level of coverage can we achieve in the available time?" changes the conversation.
AI tools can analyse stories and historical velocity to suggest test effort estimates. Monte Carlo simulation of schedule risk is accessible in commercial tools. NZ government projects require formal test estimation in gateway review submissions — the evidence-based approach satisfies both agile delivery and audit requirements.
Interview Questions
What NZ hiring managers ask about Test Estimation — and what strong answers look like.
A project manager asks you to estimate the testing effort for a new feature in a codebase you have not seen. How do you approach this?
Strong answer: I ask for: the requirement or user story, the complexity of the feature (number of user scenarios, integration points, data dependencies), the definition of done for testing, and whether any existing regression tests cover adjacent areas. I estimate using analogies — how long did testing take for the last feature of similar complexity? I add uncertainty ranges rather than point estimates: "I expect 3–5 days, but that assumes API documentation is available and the feature is testable by Tuesday." I flag risks that could widen the estimate: unclear requirements, missing test data, or a dependency on another team's component.
Junior/Mid
Your sprint has five stories and four days before the release. Testing is only one day behind development. What do you do?
Strong answer: I triage: which stories have the highest risk if they have bugs in production? I test those first, in full. For lower-risk stories, I apply a risk-based approach — test the happy path and the highest-risk edge cases rather than full coverage. I flag to the team in the daily standup that testing coverage will be partial — this is a trade-off for the team and product owner to make consciously, not a silent decision. I document which test cases are deferred and add them to the regression suite for the next sprint. Transparent trade-off management is more valuable than invisible effort compression.
Mid/Senior
Q1: Why should you never silently accept a PM's estimate for your own testing work?
Because the moment you accept it, you own it — including the blame when it proves wrong. A figure with no working behind it is a guess. Ask what it is based on, and put your work breakdown on the table as the evidence for your own number.
Q2: Write out the three-point (PERT) formula and explain why the Most Likely value is weighted.
E = (O + 4M + P) ÷ 6. The Most Likely value is multiplied by four because it is the realistic case and should dominate the estimate, while the optimistic and pessimistic values pull the result slightly toward whichever tail is longer. This anchors the estimate on reality while still accounting for uncertainty.
Q3: What makes a Work Breakdown Structure estimate more defensible than a single gut figure?
It exposes every task and its hours, so the estimate can be challenged at the line-item level rather than as a whole. If someone disagrees, they have to point at a specific task — which turns the argument into evidence about the work rather than opinion about the total.
Q4: When is metrics-based estimation the right choice, and what does it require?
When you have reliable historical data from similar past projects — test cases per story point, time per test case, defect rates. It is fast and objective, but it is only as good as your records; without trustworthy historical data it becomes guesswork dressed up as a metric.
Q5: Why should every estimate be accompanied by its assumptions?
Because the assumptions are the conditions the number depends on — "assumes a stable environment from day one." Stating them tells everyone immediately when the estimate needs revising (the moment an assumption is violated) and protects you when reality changes the conditions you priced against.
Q6: Your team is testing a new KiwiSaver balance transfer feature on an Revenue NZ myIR portal. Requirements were delivered two days before sprint start and the legacy back-end has a history of deployment delays. Which estimation approach would you use, and what additional line would you add to the WBS that a junior tester would likely forget?
A: Three-point estimation combined with a WBS is the right choice here because there are two distinct uncertainty sources: incomplete requirements and an unreliable environment. For each high-risk task (especially the balance transfer calculation and error-handling paths) you would generate an Optimistic, Most Likely, and Pessimistic figure rather than a single point. The line a junior would almost certainly omit is an explicit "environment tax" — a dedicated WBS entry covering deployment queue waits, environment resets, and data re-seeding. On legacy Revenue NZ back-ends this can absorb 20–40% of execution time; leaving it out guarantees an overrun.
Q7: What is the key difference between three-point (PERT) estimation and metrics-based estimation, and which one should a tester use when joining a team that has two years of velocity data in Jira?
A: Three-point estimation produces a weighted average from optimistic, most-likely, and pessimistic scenarios for a single task — it is useful when uncertainty is high and historical data is thin or unavailable. Metrics-based estimation derives effort from real historical numbers such as test cases per story point or average execution time per test. When a team has two years of reliable Jira velocity data, metrics-based estimation is the stronger choice because it is grounded in that team's actual pace on that codebase, making the result calibrated rather than speculative. Three-point estimation remains valuable as a secondary check on individual high-risk tasks even when the overall estimate is metrics-driven.
Q8: A team is running continuous delivery with multiple small releases to production each week and no sprint boundaries. A test lead proposes building a full WBS estimate before every release. Why is this the wrong approach, and what should the team use instead?
A: Formal WBS estimation assumes a defined scope that is stable long enough to price it — a condition continuous delivery deliberately removes. The overhead of producing and maintaining a WBS for micro-releases outweighs the benefit because scope changes before the estimate is ever useful. The right signal in this model is defect lead-time and escaped-defect rate: how quickly defects are found and how many reach production. Time-boxed exploratory charters or lightweight smoke-test checklists handle individual releases, while metrics such as test cycle time become the planning instrument instead of upfront estimates.
Q9: A developer on an Benefits NZ Benefits Portal project tells you: "Testing is simple for this story — it's just a UI label change. I've already estimated it at 30 minutes so you just need to sign off on that." What is wrong with this, and how do you respond professionally?
A: Several things are wrong. First, the developer has estimated your work — a task you own and are accountable for delivering. Second, a label change on a government portal is rarely just a label change: it may affect screen-reader accessibility (Benefits NZ portals must meet WCAG 2.1 AA), translation strings, PDF/print outputs, and regression paths through forms that reference the label. Third, 30 minutes has no working behind it. The professional response is to thank them for flagging the scope and then produce your own quick WBS on the spot — even five line items with 10-minute figures makes the estimate yours and shows the stakeholder what "30 minutes" actually covers or excludes. Never accept the number silently.
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.