Create Test Strategy
Trigger
Use when the user asks what to test, how to verify a feature, which test types are
needed, how to reduce release risk, or to write E2E tests.
When To Use
- Before or after implementation.
- Before release planning.
- When risk profile or coverage expectations are unclear.
- When a user journey needs an automated regression check.
Verify Before You Specify
A test strategy written only from reading code describes what the code appears to
do. Where a real browser is available, look at the actual behaviour first: the gap
between intended and actual is usually where the useful tests are.
sh "${CLAUDE_PLUGIN_ROOT}/scripts/playwright_cli.sh" open http://localhost:3000 --headed
sh "${CLAUDE_PLUGIN_ROOT}/scripts/playwright_cli.sh" snapshot
On Windows use scripts/playwright_cli.ps1. Both wrap
npx --package @playwright/cli playwright-cli, so no global install is needed;
they fail with a clear message if npx is absent.
The loop is open → snapshot → act on refs from that snapshot → re-snapshot
after navigation or a significant DOM change. Refs go stale. Read
references/playwright-cli-guide.md before the first command.
Skip this when there is no running app, when the change is not user-facing, or
when the user asks for a plan only.
Workflow
Inspect existing tests, package scripts, CI config, risk areas and
acceptance criteria. context/stack.json records the detected test tooling
under testing and the real commands under test_commands; use those rather
than guessing the runner.
Explore the running app with the Playwright CLI where one exists, and
record what you observed. Note behaviour that differs from the PRD: that is a
finding, not a test.
Classify required coverage across unit, integration, contract, E2E,
regression, migration, load, security and manual QA. Push each check to the
cheapest level that can actually prove it. A validation rule tested through the
browser is a slow test of a fast thing.
Tie every recommended test to a user-facing behaviour, a failure mode, or
an implementation slice. A test with no stated reason gets deleted by whoever
inherits it.
Select the E2E journeys. Only where the integration is the risk: auth, the
primary money path, a permission boundary, a multi-step flow with real
persistence. Five to fifteen specs is a healthy number for a product; sixty
means most belong a level down. Read references/e2e-patterns.md.
Author the specs (unless --strategy-only). Selectors by role and
accessible name first, then label, then data-testid. Never by CSS class.
Never waitForTimeout. One journey per spec, named after the user outcome.
Identify gates: what must pass before merge, before release, and after
release. These are different lists.
Record manual QA that is not practical to automate yet, and why.
Run what you can, and report the actual result. Never claim a test passed
unless it was run.
Validate:
python "${CLAUDE_PLUGIN_ROOT}/scripts/validate-artifact.py" <artifact paths>
Arguments
| Flag |
Effect |
--explore <url> |
Drive the browser against this URL before planning. |
--e2e |
Author E2E specs as well as the strategy document. |
--strategy-only |
Plan only. Write no spec files. |
Outputs
.project/.engineering/initiatives/<initiative-id>/testing/test-strategy.md.project/.engineering/initiatives/<initiative-id>/testing/e2e-plan.md (journeys,
selectors, data setup, gates) when E2E is in scope- E2E specs in the repo's own test location (
e2e/, tests/e2e/, or wherever the
project already keeps them)
- Exploration artifacts under
.project/.engineering/initiatives/<initiative-id>/testing/playwright/
Do not create new top-level artifact folders.
Required Front Matter
initiative_idskillcreated_atstatusconfidencesource_artifacts
Required Sections
- Coverage
- Scenarios
- Manual QA
- Required Commands
- Release Gates
Safety Constraints
- Never claim a test passed unless it was run. Report the actual output.
- Scale coverage to risk and blast radius. Exhaustive E2E is a cost, not a virtue.
- Never type real credentials into a browser command. Use environment variables or
a test account.
- Never drive a browser against production without explicit approval. Read-only
looks fine; a form submission is not.
- Do not add test dependencies the repo does not already have without saying so.
- Record residual risk where verification could not be completed.
Related Agents
qa-test-strategistfrontend-engineerbackend-engineersecurity-reviewer
1---2name: create-test-strategy3description: Use to define the automated and manual test plan for a product, feature, change, migration, release, or risk area, and to author the E2E specs. Can drive a real browser from the terminal via the Playwright CLI to verify behaviour before writing tests about it.4---56# Create Test Strategy78## Trigger910Use when the user asks what to test, how to verify a feature, which test types are11needed, how to reduce release risk, or to write E2E tests.1213## When To Use1415- Before or after implementation.16- Before release planning.17- When risk profile or coverage expectations are unclear.18- When a user journey needs an automated regression check.1920## Verify Before You Specify2122A test strategy written only from reading code describes what the code appears to23do. Where a real browser is available, look at the actual behaviour first: the gap24between intended and actual is usually where the useful tests are.2526```bash27sh "${CLAUDE_PLUGIN_ROOT}/scripts/playwright_cli.sh" open http://localhost:3000 --headed28sh "${CLAUDE_PLUGIN_ROOT}/scripts/playwright_cli.sh" snapshot29```3031On Windows use `scripts/playwright_cli.ps1`. Both wrap32`npx --package @playwright/cli playwright-cli`, so no global install is needed;33they fail with a clear message if `npx` is absent.3435The loop is `open` → `snapshot` → act on refs from that snapshot → re-snapshot36after navigation or a significant DOM change. Refs go stale. Read37`references/playwright-cli-guide.md` before the first command.3839Skip this when there is no running app, when the change is not user-facing, or40when the user asks for a plan only.4142## Workflow43441. **Inspect** existing tests, package scripts, CI config, risk areas and45 acceptance criteria. `context/stack.json` records the detected test tooling46 under `testing` and the real commands under `test_commands`; use those rather47 than guessing the runner.482. **Explore the running app** with the Playwright CLI where one exists, and49 record what you observed. Note behaviour that differs from the PRD: that is a50 finding, not a test.513. **Classify required coverage** across unit, integration, contract, E2E,52 regression, migration, load, security and manual QA. Push each check to the53 cheapest level that can actually prove it. A validation rule tested through the54 browser is a slow test of a fast thing.554. **Tie every recommended test** to a user-facing behaviour, a failure mode, or56 an implementation slice. A test with no stated reason gets deleted by whoever57 inherits it.585. **Select the E2E journeys.** Only where the integration is the risk: auth, the59 primary money path, a permission boundary, a multi-step flow with real60 persistence. Five to fifteen specs is a healthy number for a product; sixty61 means most belong a level down. Read `references/e2e-patterns.md`.626. **Author the specs** (unless `--strategy-only`). Selectors by role and63 accessible name first, then label, then `data-testid`. Never by CSS class.64 Never `waitForTimeout`. One journey per spec, named after the user outcome.657. **Identify gates**: what must pass before merge, before release, and after66 release. These are different lists.678. **Record manual QA** that is not practical to automate yet, and why.689. **Run what you can**, and report the actual result. Never claim a test passed69 unless it was run.7010. Validate:7172 ```bash73 python "${CLAUDE_PLUGIN_ROOT}/scripts/validate-artifact.py" <artifact paths>74 ```7576## Arguments7778| Flag | Effect |79| --- | --- |80| `--explore <url>` | Drive the browser against this URL before planning. |81| `--e2e` | Author E2E specs as well as the strategy document. |82| `--strategy-only` | Plan only. Write no spec files. |8384## Outputs8586- `.project/.engineering/initiatives/<initiative-id>/testing/test-strategy.md`87- `.project/.engineering/initiatives/<initiative-id>/testing/e2e-plan.md` (journeys,88 selectors, data setup, gates) when E2E is in scope89- E2E specs in the repo's own test location (`e2e/`, `tests/e2e/`, or wherever the90 project already keeps them)91- Exploration artifacts under92 `.project/.engineering/initiatives/<initiative-id>/testing/playwright/`9394Do not create new top-level artifact folders.9596## Required Front Matter9798- `initiative_id`99- `skill`100- `created_at`101- `status`102- `confidence`103- `source_artifacts`104105## Required Sections106107- Coverage108- Scenarios109- Manual QA110- Required Commands111- Release Gates112113## Safety Constraints114115- **Never claim a test passed unless it was run.** Report the actual output.116- Scale coverage to risk and blast radius. Exhaustive E2E is a cost, not a virtue.117- Never type real credentials into a browser command. Use environment variables or118 a test account.119- Never drive a browser against production without explicit approval. Read-only120 looks fine; a form submission is not.121- Do not add test dependencies the repo does not already have without saying so.122- Record residual risk where verification could not be completed.123124## Related Agents125126- `qa-test-strategist`127- `frontend-engineer`128- `backend-engineer`129- `security-reviewer`
johnoconnor0