plan-test-strategy

Test Strategy

Produce a focused test strategy that maximizes reliability gain per unit of maintenance cost. The output recommends specific test types at specific layers with explicit rationale for each — and equally important, what to skip.

Input

$ARGUMENTS = description of the feature, component, story, or area to develop a test strategy for.

Process

1. Handle Missing Input

If $ARGUMENTS is empty or contains no actionable description, prompt the user for the minimum information needed:

• What feature, component, or area needs a test strategy? — Name the feature or describe the scope.

Do not proceed until the user has provided a description of what to plan testing for.

2. Gather Context

• Read the project's CLAUDE.md for architecture, conventions, and domain language
• Scan the codebase for existing test patterns:
  • Glob for test files (**/*test*, **/*spec*, **/__tests__/**)
  • Identify test frameworks in use (package.json, go.mod, requirements.txt, etc.)
  • Note existing test organization (co-located vs. separate test directories)
• Read the code under test to understand:
  • Component boundaries and interfaces
  • External dependencies (APIs, databases, file systems, third-party services)
  • Pure logic vs. integration points vs. UI surfaces
  • Error paths and edge cases
• If a story or AC set is provided, extract the testable behaviors from acceptance criteria

3. Risk Assessment

Classify the feature/component along these dimensions:

Dimension	Low Risk	High Risk
Blast radius	Affects one user flow	Affects many flows or all users
Change frequency	Stable, rarely modified	Hotspot, frequently changed
Failure cost	Cosmetic or easily noticed	Data loss, security, or silent corruption
Complexity	Linear logic, few branches	Many branches, state machines, concurrency
External coupling	Pure logic, no I/O	Multiple external dependencies

Use the risk profile to calibrate test investment — high-risk areas justify more tests at more layers; low-risk areas may need only a single layer.