How Projects Are Delivered
Software does not arrive at your desk fully built, ready to test. It flows through a delivery process — and a tester has a job at every point in that flow, not just at the end. This lesson shows you how delivery actually works and where you add value across the whole lifecycle.
1 The Hook
Aroha landed her first QA role at an Auckland software company that builds tools for ACC claims staff. In her head, the job was simple: developers write code, the code lands in a queue, she tests it, she signs it off. Testing was the last station on the line.
By her second sprint she was drowning. Stories arrived in her column on the final afternoon, all at once. The acceptance criteria were vague, so half her bugs turned out to be arguments about what the feature was meant to do. The team started to see testing as the thing that made releases late.
Nothing was wrong with Aroha's testing. The problem was her mental model: she thought she joined the project at the end. She actually belonged to it from the first sentence of the first story. Once she understood how the project was really delivered — and where a tester fits into that flow — she stopped being the bottleneck and became the person who kept quality visible the whole way through.
This lesson gives you Aroha's corrected map on day one.
2 The Rule
Testing is not a phase at the end. It runs parallel to the entire delivery flow — and the earlier you find an issue, the more value you bring.
An ambiguous sentence in a story, a contradiction between two requirements, a missing acceptance criterion — these are defects, and they are the cheapest defects you will ever catch because no code has been written yet. You are not the person who checks the finished product. You are an embedded quality partner across the whole lifecycle.
3 The Analogy
A quantity surveyor on a building site, not the final inspector at the door.
A quantity surveyor does not wait at the front door to inspect a finished house. They are on site from the plans onward — checking the drawings make sense, watching the foundations go in, flagging that a beam is undersized before the walls hide it. They are part of the build the whole way through, and the further along a problem is found, the more expensive it is to put right. A tester works the same way across a software project. You are not the person who turns up at handover to approve the finished thing — you are on site from the first plan, keeping quality visible while it is still cheap to fix.
4 The Quality Spectrum: Predictive vs Adaptive
Every team you join sits somewhere on a spectrum between two ways of delivering software. The names change, but the underlying choice is the same: when do we validate quality, and how do we manage risk?
| Predictive (traditional SDLC / Waterfall) | Adaptive (Agile / Scrum / Kanban) | |
|---|---|---|
| When is quality checked? | Validated after construction, in a dedicated test phase once the build is complete. | Built in during construction, validated continuously as each small piece is finished. |
| How is risk managed? | By phase gates — a phase must be signed off before the next begins, so risk is controlled at formal checkpoints. | By short feedback loops — small increments and continuous validation surface problems within days, not months. |
| What the tester sees | Formal documents, planned test phases, sign-offs and traceability. | A flow of small stories, fast feedback, and testing woven through every day. |
This lesson is about the delivery flow on each side and your role within it — not the models themselves. If you want the underlying models (Waterfall, V-Model, Spiral, the SDLC phases and the STLC) taught in depth, work through The SDLC & Where Testing Fits first. Here we assume you know the phases exist and focus on what you actually do as those phases play out.
5 Agile Delivery: Ceremonies as Testing Value
On an adaptive team, work flows through a set of regular meetings called ceremonies. New testers learn what each meeting is. Good testers learn why they, as a tester, care — what value they add in each one. That is the difference between attending and contributing.
| Ceremony | Why a tester cares |
|---|---|
| Refinement & Sprint Planning | This is where testing begins. Ask "what if?", surface edge cases, and help define clear, testable acceptance criteria before a line of code is written. A story you cannot describe a pass for is a story that is not ready. |
| Daily Standup | This is about blockers and flow, not a status read-out for a manager. Raise what is stopping you — a broken test environment, missing test data, an unclear story — so the team can clear it today. |
| Sprint Review / Demo | Help present steady, user-focused workflows. Because you tested the increment, you can speak to what works, what edge cases were covered, and what risk remains. |
| Retrospective | This is your platform to flag quality bottlenecks. "Code lands in QA on the last day of the sprint" is a process problem, and the retro is where it gets fixed. Naming it is one of the most valuable things you do. |
Notice the pattern: the tester's value is highest at the start (refinement, planning) and the reflection (retro) — the points furthest from "clicking a finished screen". For the deeper detail on how a tester works inside Agile and Scrum, see Agile for Testers.
6 Living in the Board (Jira / Azure DevOps)
On almost every NZ team, the flow of work is visible on a board in a tool like Jira or Azure DevOps. The board is not admin overhead — it is the physical flow of value through the team, and as a tester you live in it. First, learn the work items.
| Story | A unit of user-facing value, written from the user's point of view, with acceptance criteria. "As a claimant, I want to upload a medical certificate so my claim can be assessed." |
|---|---|
| Task | A piece of technical work needed to deliver a story, with no standalone user value on its own. "Add the file-upload endpoint." A story is often broken into several tasks. |
| Bug | Something that does not behave as the requirement says it should. It is tracked, prioritised, and moved across the board like any other work item — not shouted across the room. |
Second, learn the column transition rules — what must be true for a work item to move from one column to the next. A board is only meaningful if a card cannot jump a column it has not earned. The most important transition for you is the one into testing.
- The developer's unit tests pass.
- The code has been merged or deployed to an environment you can reach.
- Every acceptance criterion on the story is actually met — not "mostly".
- Any test data or configuration you need to verify it is available.
When those conditions are not met, the card does not belong in your column — and saying so, politely and with the rule in hand, is part of the job. A card dragged into "Ready for Test" with failing unit tests and two unmet criteria is not ready; it is a future argument moved early.
7 Traditional / Gated Delivery: the V-Model
Not every NZ team runs sprints and boards. Government departments, banks, and heavily regulated work often deliver through a gated, predictive process — and you should be able to work in one without surprise. The clearest picture of the tester's role here is the V-Model: for every build phase on the way down, there is a matching test phase on the way up.
| Build phase (left of the V) | Matching test phase (right of the V) |
|---|---|
| Requirements | Acceptance test planning |
| System design | System test planning |
| Architecture / detailed design | Integration test planning |
| Coding | Unit test execution |
The point of the V is that the test on the right is planned while the matching build phase on the left is written, then run on the way back up. You write the acceptance tests when the requirements are written, not when the system is finished. Testing starts early even in a "test at the end" world.
Gated delivery also comes with formal artefacts you will read, interpret, and eventually author:
| Test Strategy & Test Plan | The strategy sets the overall approach to quality; the plan sets scope, schedule, environments, and exit criteria for a specific piece of work. You will read and interpret these long before you author one. |
|---|---|
| Requirements Traceability Matrix (RTM) | A table that maps every test case back to the requirement it covers, so the team can prove coverage — every requirement has a test, and no test exists without a reason. Auditors ask for this. |
| Formal Defect Triage | A regular meeting where defects are reviewed, prioritised, and assigned, so the team decides — deliberately and on the record — what gets fixed before the gate. |
8 Your Practical Onboarding Progression
Knowing the theory is one thing; finding your feet on a real team is another. Whether the team is adaptive or gated, your first weeks follow the same three phases. Do not try to skip to phase three on day one.
- Phase 1 — Shadow & Observe Sit in on the ceremonies or the phase-gate meetings. Watch how work actually flows. The single most useful thing you can do early is map the lifecycle of one real bug — from the moment it is discovered, through triage, fix, re-test, and finally its closure in production. That one trace teaches you the whole delivery flow in miniature.
- Phase 2 — Reverse-engineer a Feature Take a feature that already shipped and work backwards. On an Agile team: read its story and acceptance criteria, then read the test cases that were written against it — see how the criteria became checks. On a gated team: take the requirements document and map it to the test scripts that prove it. You learn the team's standard of "done" by studying finished work.
- Phase 3 — Co-pilot a Live Ticket or Phase Now do it for real, with support. Write the test conditions or acceptance tests for a live story or requirement. Refine them with a senior tester. Execute them. Then move the ticket — or the artefact — to done by the team's own rules. You are now part of the delivery flow, not watching it.
The progression is the same shape on both sides of the quality spectrum: understand the flow, study how the team does quality, then take part. The artefacts differ — a Jira ticket here, a requirements document there — but the move from observer to contributor is identical.
9 The Hybrid Reality
Here is the thing nobody tells you in a course: very few real NZ teams sit cleanly at one end of the spectrum. Most blend predictive governance with adaptive delivery. They run sprints and a board — but they also keep a detailed project plan, formal sign-offs, and a dedicated UAT phase before release because a regulator, a bank, or a government agency requires it.
So do not be surprised when a team says "we're Agile" and then hands you a Gantt chart and books a two-week UAT window. That is not a contradiction or a broken team — it is the common shape of delivery in regulated NZ contexts: IRD, Kiwibank, Waka Kotahi, ACC, Te Whatu Ora, and many MBIE-related programmes all run blends like this.
Your job is to read which parts of your team are adaptive and which are gated, and bring the right tools to each. Surface edge cases in refinement and keep your traceability tidy for the audit. The two are not enemies.
10 Common Mistakes
🚫 Treating testing as the last station on the line
I used to think: My job starts when finished code lands in my column.
Actually: Your job starts at the first sentence of the first story. An ambiguous requirement is a defect, and it is the cheapest one you will ever catch. Get into refinement and planning — that is where testing begins.
🚫 Letting cards skip their column transition rules
I used to think: If a developer drags a card into "Ready for Test", it is my job to test it.
Actually: A card belongs in your column only when the agreed rules are met — unit tests pass, all acceptance criteria met, an environment you can reach. Accepting work that has not earned its column just moves the argument to the end of the sprint.
🚫 Assuming every team delivers the same way
I used to think: I learned Agile, so every team runs sprints and a board.
Actually: NZ teams sit all along the spectrum, and most are hybrids — sprints plus a detailed plan plus a UAT phase. Read which parts of your team are adaptive and which are gated, and bring the right tools to each.
The trap that catches every new tester
All three mistakes share one root cause: thinking of testing as a phase you own at the end, rather than a thread you run through the whole delivery flow. Fix the mental model and the specific mistakes mostly fix themselves.
11 Now You Try
Three graded exercises: write acceptance criteria from a vague story, judge a column transition, then map a bug's lifecycle. Write your answer, run it for AI feedback, then compare to the model answer.
A product owner at a fictional Kiwibank online-banking team drops this story into refinement:
Write at least 3 clear, testable acceptance criteria AND name 2 edge cases the story does not cover:
Show model answer
Good acceptance criteria describe a behaviour you can write a pass/fail check against. Three strong ones: 1. Given a logged-in customer with sufficient available balance, when they transfer a valid amount to a valid NZ account number, then the amount is debited from their account and credited to the payee, and a confirmation is shown. 2. Given a transfer amount greater than the available balance, when the customer submits, then the transfer is declined with a clear "insufficient funds" message and no money moves. 3. Given an invalid or incomplete account number, when the customer submits, then the transfer is blocked and the field is flagged with a specific validation message. Two edge cases the story does not cover (any sensible two earn marks): - A transfer that hits the customer's daily transfer limit. - A zero, negative, or non-numeric amount. - A transfer to the customer's own account. - Behaviour when the payment network or backend is unavailable mid-transfer. - Duplicate submission (double-click) creating two transfers. The trap to avoid: criteria like "the transfer works" or "money is sent" are not testable — they do not state the precondition, the action, and the observable result. The value you add here is turning a one-line wish into conditions a developer can build to and you can verify, before any code exists.
On a fictional Waka Kotahi licence-renewal team's Jira board, a developer drags a story from In Development into Ready for Test. The team's agreed rule for that transition is: developer unit tests pass, the change is deployed to the test environment, and every acceptance criterion is met.
Two of the three unit tests pass and one is failing. The change is on the test environment. One of the four acceptance criteria (handling an expired licence) is not yet built. The developer says “it's basically done, you can start testing the rest.”
Decide: is the story allowed to move to Ready for Test? Justify against the column-transition rules:
Show model answer
Decision: Not allowed. The story does not meet the agreed transition rules, so it should not move to Ready for Test. Which rules are met: the change is deployed to the test environment — that one condition is satisfied. Which rules are not met: (1) Developer unit tests do NOT all pass — one is failing, so the "unit tests pass" rule is broken. (2) NOT every acceptance criterion is met — the expired-licence criterion is not built, so a quarter of the story's defined behaviour does not exist yet. How to handle it: this is not a personal argument, it is the agreed rule applied evenly. Point to the column rule the team set: "Our rule for Ready for Test is unit tests pass and all AC met. The failing test and the missing expired-licence criterion mean it's not there yet." Offer the constructive path: keep the card in In Development, and if it helps, agree to pair on the failing test or pull the expired-licence behaviour into a separate story so the rest can flow. The point is that "basically done" is not a column rule — and accepting work that has not earned its column just moves the failure to the end of the sprint.
A tester on a fictional Te Whatu Ora patient-portal team finds that uploading a large document silently fails — no error, the file just never appears. The team works in Agile sprints with a Jira board. Map this bug's lifecycle from discovery all the way to its closure in production, in the team's methodology.
Show model answer
A strong map traces the bug as a work item moving across the board, with the tester active at both ends: Step 1 — Discovery: the tester reproduces it reliably and isolates the trigger (file size threshold), capturing steps, expected vs actual, environment, and evidence (a screen recording, the file used). A bug you cannot reproduce is not yet ready to raise. Step 2 — Raising / logging it: create a Bug work item on the Jira board with a clear title, reproduction steps, severity (silent data loss in a health portal is high), and the evidence attached. Link it to the affected story if relevant for traceability. Step 3 — Triage and prioritisation: the bug is reviewed in triage / refinement, where the team agrees priority and pulls it into a sprint (a high-severity health-data bug likely jumps the queue). It moves into the development columns. Step 4 — Fix and verification: a developer fixes it; their unit tests pass and it deploys to the test environment (the Ready for Test rules). The SAME tester verifies the fix against the original steps, confirms a clear error or successful upload now occurs, and runs a quick regression on related upload paths. Only the tester who can confirm it is fixed should close it. Step 5 — Release and closure in production: the fix ships in a release; the tester runs a smoke check in production to confirm the large upload now works for real, then moves the bug to Done/Closed. Closure is in production, not at the moment the developer says "fixed" — the bug's lifecycle ends when it is verified gone where users actually are. The key idea being assessed: the tester owns both ends of the lifecycle (find it, and confirm it is truly gone in production), and the bug travels as a tracked work item across the board the whole way — it is never just shouted across the room and forgotten.
12 Self-Check
Click each question to reveal the answer.
Q1. What is the difference between predictive and adaptive delivery, in terms of quality and risk?
Predictive (traditional SDLC / Waterfall) validates quality after construction and manages risk with phase gates — each phase is signed off before the next begins. Adaptive (Agile / Scrum / Kanban) builds quality in during construction and manages risk with short feedback loops and continuous validation. Most NZ teams sit somewhere between the two.
Q2. Why does a tester care about refinement and the retrospective specifically?
Refinement is where testing begins — you ask "what if?", surface edge cases, and help define testable acceptance criteria before code is written, which is the cheapest place to catch a defect. The retrospective is your platform to flag quality bottlenecks — like code landing in QA on the last day of the sprint — so the process itself gets fixed.
Q3. What must be true for a story to move from In Development to Ready for Test?
The agreed column-transition rules must all be met — typically the developer's unit tests pass, the change is on an environment you can reach, and every acceptance criterion is actually met. "Basically done" is not a column rule. A card that has not earned its column does not belong in it.
Q4. In the V-Model, when do you plan the acceptance tests?
While the requirements are being written — not at the end. The V-Model pairs each build phase on the left with a matching test phase on the right (requirements↔acceptance test planning, system design↔system test planning, architecture↔integration test planning, coding↔unit test execution). The test is planned as its matching build phase is written, then run on the way back up. Even in a gated process, testing starts early.
Q5. A new team tells you "we're Agile" but also hands you a detailed plan and books a two-week UAT phase. Is something wrong?
No — that is the hybrid reality, and it is the common shape of delivery in regulated NZ contexts (IRD, Kiwibank, Waka Kotahi, ACC, Te Whatu Ora). Most teams blend predictive governance with adaptive delivery. Read which parts are adaptive and which are gated, and bring the right tools to each: surface edge cases in refinement, and keep your traceability tidy for the audit.