THE GITHTML FIELD GUIDE
Test strategy template organized around product risk
A test strategy should explain which failures matter, where they can be detected, and what evidence supports release decisions. Start with user risks, map each risk to an appropriate test level, and document important gaps. A list of test tools or a coverage percentage alone does not describe a strategy.
List the failures worth preventing
Begin with concrete outcomes: a user loses unsaved work, a duplicate request creates duplicate records, or a permissions change leaves old access active. These illustrative risks are more actionable than a goal such as improve quality. Rank them using impact and likelihood appropriate to the project, explaining uncertainty instead of producing arbitrary precision. The Practical Test Pyramid discusses tests at different levels; use that as background for choosing where a behavior can be checked most directly. Do not assume every important risk needs a full browser test.
Map each risk to evidence
An illustrative duplicate-submission row might name the invariant, a unit test for the deduplication rule, an integration test for persistence, and a small end-to-end check of the user message. State what each test proves and what it leaves untested. Include data setup, cleanup, and the conditions needed to reproduce failures. A test name without an assertion is weak evidence. Distinguish tests that currently exist from proposed additions, and record skipped or flaky checks rather than counting them as dependable coverage.
- Risk: describe a user-visible failure or broken invariant.
- Evidence: link a test and explain the behavior its assertion protects.
- Gap: name missing coverage, the owner, and the release consequence.
Define the decision, not just the suite
Write the release gate in terms the team can evaluate: required checks, acceptable known failures, and the authority to grant an exception. Avoid a blanket promise that passing tests prove correctness. Include manual checks where human judgment is necessary and make their procedure repeatable. Review the strategy when a major boundary or data model changes. A compact HTML report can summarize the strategy for review on a phone, but preserve links to exact test revisions and dated results so the summary cannot be mistaken for a live test runner.
Sources and further reading
AI-assisted writing with source-linked guidance and illustrative examples. Read our editorial approach or report a correction.