Test Case Template
A copy-paste ready template for writing formal test cases — with field-by-field guidance, good vs. bad examples, and a fully worked NZ scenario.
1 What this covers
A formal test case is a structured, reusable record that documents exactly what to test, how to test it, and what to expect. It is not the right tool for every situation. Use it when:
- You need an audit trail — e.g. regulated industries (financial services, health), government systems, or any project requiring compliance sign-off.
- The same test will be run multiple times across releases or by different testers, and you need consistent results.
- A step-by-step regression suite is handed to another team or an offshore partner who cannot rely on tribal knowledge.
- A stakeholder or client requires documented evidence of test coverage (e.g. CoverNZ, Revenue NZ, or a council system).
When not to use a formal test case:
- Exploratory sessions — use a charter and session notes instead. The discovery mindset is lost if you pre-script every step.
- Fast-moving prototype work where the UI changes weekly — maintenance cost exceeds value.
- Simple smoke checks that are self-evident (“does the page load”).
2 The Template
Copy the block below into your test management tool (TestRail, Zephyr, Xray, a spreadsheet, or a plain document). Every field is explained in the Field Guide below.
3 Field Guide
Each field has a job. Weak fields are the most common cause of tests that produce ambiguous results or cannot be re-run by someone else.
| Field | Purpose | Good example | Bad example |
|---|---|---|---|
| Test Case ID | Unique identifier so the case can be referenced in defect reports and traceability matrices. | TC-KS-042 |
Test 1 or left blank |
| Title | One-line description of the scenario being verified. Should name the feature, the action, and the key condition. | Employer KiwiSaver rate change: 3% to 6% saves correctly | Test KiwiSaver |
| Preconditions | Everything that must be true before step 1 runs. Missing preconditions are the top cause of unreproducible failures. | Logged in as employer with Revenue NZ number 123-456-789; employee record exists with current rate 3%; test environment pointing to UAT stub for Revenue NZ gateway. | User is logged in |
| Test Steps | Numbered actions a tester performs. Each step should be a single, unambiguous action, not a paragraph. | 1. Navigate to Employee → Contribution Settings 2. Click the Employer Rate field and change value from 3 to 6 |
1. Go to KiwiSaver settings and update everything |
| Expected Result (per step) | What the system should do immediately after each step. Inline expected results catch defects at the exact point of failure rather than at the end. | Step 2 Expected: Field accepts numeric input; no validation error shown | Step 2 Expected: Works |
| Expected Result (overall) | The final pass condition — the state the system should be in at the end of all steps. | Contribution rate displays as 6% on Employee Summary; audit log records the change with tester username and timestamp; no error email sent to Revenue NZ gateway. | KiwiSaver rate is updated |
| Actual Result | Filled in only during execution. Describes exactly what happened — including error messages verbatim. | Rate displayed as 6% on summary. Audit log entry created at 14:32 NZST. No gateway error. | It worked / It failed |
| Status | The outcome of execution. Blocked means the test could not run due to an external dependency, not that it failed. | Pass / Fail / Blocked / Not Run | OK / Done / N/A |
| Notes | Anything a future tester needs to know: defect IDs, environment gotchas, screenshots, workarounds applied, or assumptions that were made. | DEF-214 raised. Screenshot attached. RealMe login stub used — real credential check not available in UAT. | Left blank |
| Tester / Date | Accountability and traceability. Required for regulated projects and useful for spotting if a tester pattern-matched rather than actually executing. | S. Tahi — 27 Jun 2026 | Left blank |
4 Worked Example
A KiwiSaver employer portal allows employers to update the voluntary employer contribution rate for an employee. The following test case verifies that changing the rate from 3% to 6% is saved, displayed, and logged correctly.
5 Variations
The base template above is format-agnostic. The same information can be expressed in different styles depending on what your team or tool requires.
ISTQB-aligned test case format
Adds explicit traceability fields used in test management tools like TestRail or Zephyr. Required for CTFL-aligned test plans.
Given / When / Then format
Used when tests are automated with Cucumber, Playwright BDD, or SpecFlow. Written in plain language so product owners can read and verify scenarios. The same KiwiSaver example in Gherkin:
Session-based exploratory note
Not a test case — a lightweight record for exploratory sessions. No numbered steps. Captures charter, time-box, observations, and follow-ups. Use this when you are discovering behaviour, not re-running a known script.
6 Common Mistakes
1 — No preconditions
A test case without preconditions cannot be reproduced reliably. The tester who wrote it knows what setup they did implicitly. Everyone else gets inconsistent results and blames the test. Write preconditions as if handing the test to someone who has never seen the system.
2 — Vague expected results
"The page updates correctly" is not an expected result. Specify exactly what should change: which element, what text, what value, within what time. "The Contribution Settings card displays 'Current employer rate: 6%' without a page hard-refresh" is testable. "Correctly" is not.
3 — Testing multiple things in one case
A single test case that checks rate update, audit log, email notification, payroll integration, and error handling is impossible to triage when it fails. One scenario per case. If the rate update passes but the audit log fails, you need separate cases to isolate which is failing.
4 — Step-result mismatch
A test with 6 steps and only one overall expected result at the end misses defects mid-flow. If step 3 produces a subtle wrong state that only manifests at step 5, you will not know where the defect is. Add an inline expected result to every step that changes system state.
5 — Missing negative tests
Most test suites are heavy on happy path and light on failure scenarios. For every acceptance criterion ("user can update the rate"), write at least one negative case ("user cannot set rate below 3%", "user cannot set rate to a non-numeric value"). The compulsory KiwiSaver minimum is exactly the kind of business rule that breaks under negative input.
7 Copy-Paste Block
Clean Markdown version suitable for pasting into Confluence, Notion, GitHub Issues, or a plain text file.
From the field
An NZ fintech startup spent three months building an automated test suite. When their lead tester left, the new hire could not run the suite without help — the test cases had no preconditions documented, and the expected results were written as "should work correctly." Half the tests were green but covering the wrong thing. The team rewrote the suite using a structured test case template that required preconditions, exact steps, and specific expected results. The new suite took four weeks to rebuild but the new hire was independent within one week of starting. Clarity in test design is a knowledge transfer mechanism, not just a quality gate.
Senior engineer insight
The test case description should be written for the person who runs it six months after you wrote it with no prior context. "Enter valid data and click Submit" is not a test case — it is a reminder note to yourself. "Enter a customer name of exactly 50 characters (the maximum length per spec section 3.2) and verify the success message reads exactly: Record saved" is a test case. The investment in precision pays back every time someone else runs it or re-runs it after a change.
Writing test cases that only the author can run correctly because the steps assume undocumented context.
Why teams fail here
- Test cases reference "test data from last sprint" with no specification of what that data was
- Pass/fail criteria are subjective — "UI looks correct" with no definition of correct
- Test cases are written once and never updated when the feature changes — executing stale test cases wastes time and produces false results
- Too many steps per test case — one test case covering an entire workflow makes it impossible to pinpoint which step failed
Key takeaway
A test case is a reusable, transferable execution contract — write it so anyone can run it and get the same result.