copy paste

skills/software/test-strategy.md

@@ -0,0 +1,45 @@
+# 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.