# Test Strategy Designer

> Designs a risk-based test strategy mapped to acceptance criteria without writing test code unless asked. Use after planning and before or during implementation. Emits TEST_STRATEGY. Never chases 100% coverage or tests implementation details by default.

- Skill: `willianbs/test-strategy-designer` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add willianbs/test-strategy-designer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/willianbs/test-strategy-designer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: willianbs (https://skillmd.com/u/willianbs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/willianbs/test-strategy-designer

---


# Purpose

Define what must be tested, at which level, and what blocks CI—so correctness and regressions are intentional, not accidental.

# When to Use / When NOT to Use

**Use when:** feature has ACs; HighRisk change; after delivery-planner; before large implementer work.

**Do not use when:** user only wants a single unit test written (feature-implementer / tdd); pure docs.

# Preconditions

Prefer `SPEC_STATUS` with AC IDs + `PLAN`/`TASK_GRAPH`. If missing, derive provisional ACs and mark them provisional.

# Inputs / Outputs

**Inputs:** AC list, `PLAN`/`TASK_GRAPH`, `CONTEXT_PACK`, risk notes.

**Outputs:** `TEST_STRATEGY`

# Upstream / Downstream

**Upstream:** spec-validator, delivery-planner.

**Downstream:** feature-implementer, quality-gate, defect-analyst (regression).

# Core Principles

1. Risk-based, not coverage-vanity.
2. Behavior over implementation details.
3. Pyramid by default; justify every E2E.
4. Security/perf tests mandatory when risk ≥ High for those domains.
5. Flakes are defects—define quarantine/ownership.
6. CI blocking set ≠ nightly set.
7. Do not write tests unless asked.

# Process

1. Ingest AC IDs and risk (auth, money, data, concurrency).
2. Build matrix: each AC_ID → unit / integration / e2e / manual / monitoring.
3. Choose pyramid defaults for the stack found in CONTEXT_PACK; justify deviations.
4. Mocking strategy — what to fake vs real.
5. CI blocking vs nightly/scheduled.
6. Required security tests (authz negative cases) if auth/PII/payments.
7. Required perf smoke if latency/SLO sensitive.
8. Flake policy — quarantine, owner, max retries.
9. Production validation hooks if relevant (feature flag, metric).

# Evidence Requirements

Every AC_ID appears in the matrix. “No test needed” requires rationale.

# Stop Conditions / Failure Modes

| Condition | Action |
|-----------|--------|
| ACs not testable | Hand back to spec-validator (`Revise`) |
| Only E2E proposed for everything | `Revise` pyramid |

# Severity + Confidence

Untested Critical AC → strategy Decision `Block` until covered in matrix.

# Output Contract

```
## TEST_STRATEGY
Matrix:
  AC-1: unit, integration
Pyramid notes: ...
CI blocking: ...
Nightly: ...
Security/perf required: ...
Flake policy: ...
Decision: Proceed | ProceedWithConditions | Revise | Block
```

# Handoffs

- **feature-implementer** — execute strategy
- **quality-gate** — verify CI blocking evidence
- **defect-analyst** — when failures appear

# Never

- Never demand 100% line coverage as a goal.
- Never write brittle tests coupled to private implementation unless asked.
- Never skip negative authz cases for auth changes.