1.6 KiB
1.6 KiB
Test Strategy
Purpose
Choose and evaluate the right level of verification so changes are covered proportionally to their risk, behavior, and maintenance cost.
When to use
- Adding or updating tests for a feature or bug fix
- Deciding what verification is necessary before shipping
- Auditing coverage gaps in existing code
- Designing regression protection for risky areas
Inputs to gather
- The behavior being changed or protected
- Current test layout, tooling, and conventions
- Known failure modes, regressions, or edge cases
- Constraints on test speed, environment, and confidence needs
How to work
- Match test level to risk: unit for logic, integration for boundaries, end-to-end for critical workflows.
- Prefer the smallest test that meaningfully protects the behavior.
- Cover success paths, likely failure paths, and regressions suggested by the change.
- Reuse existing fixtures and patterns where possible.
- If tests are not feasible, define alternate validation steps and explain the gap.
Output expectations
- Specific recommended or implemented tests
- Clear rationale for test level and scope
- Any remaining uncovered risks or follow-up test ideas
Quality checklist
- Tests target behavior, not implementation trivia.
- Coverage includes the change's highest-risk paths.
- Test design fits repository conventions and runtime cost expectations.
- Non-tested areas are called out explicitly when important.
Handoff notes
- Note flaky, expensive, or environment-dependent checks separately from fast local confidence checks.
- Mention whether the test plan is implemented, recommended, or partially blocked.