Test Strategy And Risk — Claude Code Guide

Testing strategy starts with risk

The “generate tests” command is not a strategy. First determine which behavior must be proven, which failures are most expensive, which test level will provide the best signal, and what will deliberately remain outside the PR.

Claude Code can help design a set of checks and map risks, but the engineer remains responsible for deciding whether testing is sufficient.

Read the specification and acceptance criteria.
Review changed and related files.
Identify business risk and change risk.
Record TEST_STRATEGY.md or a strategy section in the task.
Choose test levels for priority scenarios.
After implementation, run checks and analyze the diff.

Two dimensions of risk-based testing

Dimension	Examples of signals
Business risk	Money, access, data, public API, critical user flow, trust
Change risk	Large diff, several layers, new module, weak coverage, integrations
High priority	Both risks are significant — stronger and more precise evidence is needed
Low priority	Small change and low cost of failure — local verification is sufficient

Do not confuse plan and review levels

L1 verification can mean a general plan: regression, API, and smoke checks are needed. L2 verification details specific scenarios, test levels, and their rationale. Layer 2 review is a separate CI or review stage, not the name of a test level.

Decision	Question
L1 verification	Which categories of checks are needed?
L2 verification	Which specific inputs, levels, and assertions are needed?
Layer 2 review	Can the technical gate allow the change to proceed?

Example TEST_STRATEGY.md

Minimal strategy structure

# Test strategy

## Unit
- ...

## Integration / API
- ...

## Smoke
- ...

## Manual checks
- ...

## Risks not covered
- ...

Coverage is an indicator, not a goal

A high coverage percentage does not guarantee protection for a critical flow.
Coverage helps reveal blind spots and coverage drops after changes.
Secondary formatters can increase the number without protecting a refund or payment flow.
The main criterion should be the quality of evidence for risky behavior.
During planning, Claude should not immediately generate test code.