Test Estimation, Prioritisation & Planning
The work that separates a tester from a test lead.
Anyone can run a test. A lead is the person who can say how long the testing will take, what to test first when the date will not move, and how the team will know it is safe to release. This track teaches the three skills behind those answers — estimation, risk-based prioritisation, and planning — for the fixed-date bank and government go-lives you actually work on.
Three skills, not one
Estimation, prioritisation, and planning get lumped together as “the planning stuff” and treated as a single chore done once at the start of a release. They are three distinct skills, and a lead who is strong at one and weak at the others still gets caught out.
Estimation answers “how much testing effort will this take?” It is a forecast under uncertainty, and the hardest part is not the maths — it is communicating a range honestly to people who want a single date. A lead who gives a confident single number, then misses it, loses trust they never get back.
Prioritisation answers “what do we test first, and what do we cut, when there is not enough time?” There is never enough time. The lead who can rank the test backlog by risk — and defend cutting the bottom of it — is the one who ships safely on a fixed date. The lead who tests in the order things were built runs out of time on the things that matter.
Planning answers “how will we run this testing, and how will we know it is safe to release?” A fit-for-purpose test plan is not a forty-page template nobody reads. It is a short, sharp statement of scope, approach, entry and exit criteria, and what feeds the go/no-go call. For a Te Whatu Ora or IRD release with a fixed go-live, that document is what lets a delivery manager sleep.
You can be a brilliant test executor and still sink a release by estimating badly, prioritising the wrong things, or having no plan a stakeholder can read. This track builds the three skills in order, because they feed each other: a good estimate sets up an honest prioritisation conversation, and both feed a plan that survives contact with a real go-live date.
From estimate to plan
Test Estimation Techniques
Three-point and PERT estimation, analogy-based estimation, and how to communicate uncertainty. Why an estimate is a range, not a promise — and how to handle the “there’s no time for testing” conversation.
~30 min read · ~70 min with exercises · Lead
Lesson 2Risk-Based Prioritisation
Likelihood × impact matrices, deciding what to test first when time is short, cutting scope you can defend, and the regression-versus-new-feature trade-off on a fixed-date release.
~30 min read · ~70 min with exercises · Lead
Lesson 3Test Strategy & Planning
A fit-for-purpose test plan that is not a forty-page template. Entry and exit criteria, stakeholder escalation, and the inputs that feed a go/no-go decision on a fixed-date go-live.
~30 min read · ~70 min with exercises · Lead
The fixed date is the whole problem
Most of the hard testing decisions in NZ come from one fact: the date is fixed and the scope is not. A bank ties a release to a regulatory deadline. IRD ships changes to align with the start of a tax year. Te Whatu Ora schedules a system cut-over for a weekend that was booked months ahead. The go-live will not move, so when development runs late — and it usually does — the testing window is what gets squeezed.
That is where a lead earns their title. Not by testing faster, but by estimating honestly enough that the squeeze is seen coming, prioritising sharply enough that the most dangerous defects are still found in the time that is left, and planning clearly enough that everyone agrees in advance what “safe to release” means — so the go/no-go call is a calm reading of evidence, not an argument at 9pm the night before.
This track is the lead-level companion to the hands-on testing tracks. It assumes you can already test. What it adds is the judgement and the conversations that let you carry a release.