The Capstone — A Simulated NZ Testing Job
Seven weeks. One product. Every artefact a real tester ships.
This is not a set of disconnected exercises. It is a single, running job on one fictional New Zealand product — the Tūāpapa KiwiSaver member portal. Each week you arrive at the same desk, pick up where you left off, and produce the work a QA does on a real team: clarifying questions, test cases, execution evidence, a defect report, a regression plan, a release recommendation, and finally a blameless post-mortem after a production incident. By the end you will have built a portfolio of artefacts you can show in an NZ QA interview.
Tūāpapa KiwiSaver — the new member portal
Tūāpapa is a fictional New Zealand KiwiSaver provider with around 180,000 members. Its old member portal is a tired website that members use to check their balance, change their contribution rate, switch funds, and update their details. The board has funded a full rebuild: a new responsive portal that members reach with their RealMe login, pulling balances from the fund administration system and verifying IRD numbers against a back-end service.
You have just been placed as the QA on this rebuild. The deadline is real, the product owner is busy, the requirements are imperfect, and a regulator — the FMA — cares a great deal about whether members can be misled about their money. Over seven weeks you will test this portal from first requirement to first production incident.
The same fictional company, the same portal, and the same characters appear in every week. Keep your artefacts — the test cases you write in Week 2 are the ones you execute in Week 3, the defects you log in Week 4 feed the regression plan in Week 5, and the incident in Week 7 is rooted in decisions made earlier.
Your first job, week by week
Requirements & Clarifying Questions
A pile of user stories lands in your inbox. Review them, find the ambiguities, and write the clarifying questions that stop a defect being built before a line of code is written.
~30 min read · ~70 min with exercises
Week 2Test Design
The requirements are clarified. Now turn them into test cases — equivalence partitions, boundary values, and negative paths — with clear steps and expected results a teammate could run.
~30 min read · ~75 min with exercises
Week 3Execution & Evidence
Run your tests against the first build. Record pass, fail, and blocked with the evidence a test result needs — the build, the data, the steps, and what you saw versus what you expected.
~30 min read · ~70 min with exercises
Week 4Defect Reporting
A test failed. Turn it into a defect a developer can fix without a single follow-up question — reproducible steps, clear severity, the right evidence, and no blame.
~30 min read · ~70 min with exercises
Week 5Regression Strategy
A fix is in and the release is close. You cannot re-run everything. Build a risk-based regression plan that protects the member's money without blowing the timeline.
~30 min read · ~75 min with exercises
Week 6Release & Reporting
Go or no-go? Weigh the evidence, make a release recommendation you can defend, and write the executive summary the product owner takes to the board.
~30 min read · ~75 min with exercises
Week 7Incident Review — Chaos Day
The portal is live and several things break at once. Diagnose the failure chain across a bad API deploy, a broken locator, an accessibility failure, and a race condition — then write the blameless post-mortem.
~35 min read · ~85 min with exercises
The job is the sum of the parts
Most learners can write a test case in isolation. Far fewer can take an imperfect requirement, turn it into tests, run them, log what breaks, decide what to re-test, recommend a release, and then stand up after an incident and explain what went wrong without pointing a finger. That sequence is the job. Doing each step on the same product, with decisions that carry forward, is the only way to learn how the steps connect.
The artefacts you produce here are deliberately the ones an NZ employer asks to see: a set of clarifying questions, a test suite, a defect report, a regression plan, a release recommendation with an executive summary, and a post-mortem. Keep them. They are your evidence that you can do the work, not just describe it.