Library · Templates

Templates Library

The artefacts professionals actually use

Seven copy-paste-ready templates covering the full QA lifecycle — from a single test case to a programme-level test strategy. Each template is opinionated enough to be useful on day one and structured enough to satisfy NZ government and enterprise stakeholders.

What’s in this library

Test Case Bug Report Test Plan Test Strategy Risk Register Playwright Boilerplate Test Report

Format

Every template ships as an annotated copy-paste block with field-by-field guidance, a filled NZ example, and a checklist to verify the artefact before you hand it to a developer, product owner, or procurement panel.

Who this is for

Grad and junior testers building their first artefacts, seniors who want a consistent team baseline, and test leads producing documents for NZ government and enterprise assurance reviews.

7 templates

Pick a template

About this library

Why templates matter

Most testers spend time re-inventing artefacts from scratch. A blank Confluence page becomes a half-finished test plan. A bug reported in a Slack message gets ignored. A test strategy written from memory omits the sections a procurement panel needs to sign off.

These templates solve that problem. They encode the professional standard for each document so you can focus on the content — the feature under test, the risk, the environment — not the structure.

NZ-context aware

The test strategy and risk register templates include sections required for NZ government ICT procurement, the Government Assurance Programme (GAP), and the Privacy Act 2020. They are immediately usable on NZGP and public sector contracts.

ISTQB-aligned

Each template maps to the relevant ISTQB process area: test case and test plan align to CTFL Chapter 5, test strategy to CTAL-TM Chapter 2, and risk register to the risk-based testing process in CTAL-TM Chapter 2.5. Field labels follow the ISTQB glossary.

Annotated, not just blank

Every field has guidance text in italics and a filled NZ example alongside the blank version. You can delete the guidance when you hand the document over. New team members can read it to understand why each field exists.

Consistent across the team

Adopt these as your team baseline and every bug report, test case, and sign-off document follows the same structure. Developers stop ignoring bug reports that are missing information. Stakeholders get reports they can actually read.

Where to go next