test-strategy

name	test-strategy
description	Use in a Wakeflow Test window to design a risk-based validation plan for a controller test card, real-project scenario, release check, runtime observation, or cross-repository integration question.

Test Strategy

Design the smallest real validation plan that answers the controller's question with credible evidence. This skill belongs to Test windows. It plans and collects evidence; it does not accept product work or dispatch follow-up implementation.

Source Skills Used

• senior-qa: risky user journeys, test layer choice, must-pass automated tests, focused manual checklist, and flakiness as a product bug.
• code-reviewer: evidence should cover correctness, safety, maintainability, performance, and tests when relevant.
• Industry basis: risk-based testing, test pyramid, and evidence confidence.

Wakeflow Role

Use this skill only when Test is justified by one of these:

• real project/environment verification;
• cold-start, dashboard, runtime, daemon, or monitoring observation;
• reproduction/regression that the controller cannot safely perform alone;
• cross-repository integration evidence;
• release or smoke confidence.

Do not use Test to rediscover defects already known to the controller or to run general QA without a boundary.

Required Inputs

• Controller test card or state-root reference.
• Exact question Test must answer.
• Target repository/window.
• What the controller/product window already self-verified.
• Success meaning.
• Failure meaning.
• Invalid conclusions.
• Stop conditions.

If those inputs are missing, stop and report missing test boundary evidence.

Workflow

1. Restate the question.
   • What decision will this evidence enable?
   • What must not be concluded from this run?
2. Map risk.
   • Critical user journey.
   • Money/auth/data loss/privacy/security risk.
   • Integration boundary.
   • Runtime or environment dependency.
   • Known flaky area.
3. Choose test layer.
   • Unit for isolated logic.
   • Integration for boundary behavior.
   • E2E/manual for key user-visible or environment-dependent paths.
   • Runtime/log/dashboard observation only when the question needs real operational evidence.
4. Define evidence.
   • Commands.
   • Reports, logs, screenshots, runtime JSON, or traces.
   • Expected pass/fail signal.
   • Re-run or flake handling rule.
5. Run only the agreed boundary.
6. Return evidence and interpretation without accepting product completion.

Evidence Plan Format

## Test Strategy

- Question:
- Target:
- Why Test is needed:
- Risk focus:
- Test layer:
- Commands or observations:
- Expected success signal:
- Failure signal:
- Invalid conclusions:
- Stop conditions:
- Evidence paths:

Flakiness Rule

Treat flakiness as evidence degradation, not as "mostly passing". If a result is flaky:

• record reproduction rate or affected command;
• identify likely category when possible;
• do not call the tested behavior accepted;
• route to debugging/triage or owning repository.

Allowed Outputs

• Test plan or strategy note.
• Test evidence summary.
• Failure classification.
• Recommendation for controller review.

Forbidden Outputs

• No final acceptance.
• No product implementation unless the test card explicitly authorizes it.
• No unbounded exploratory QA.
• No target-to-target dispatch.
• No global TODO mutation.

Quality Bar

A good strategy names the exact question, risk, chosen layer, evidence, success meaning, failure meaning, invalid conclusion, and stop condition. It fails if it just says "run tests" or expands beyond the controller's test boundary.

Challenge path dependency before executing

Before committing to a test approach, ask: is this chosen because it fits THIS demand's risk, or because it is what was done last time? Path-dependent reuse is the common way a wrong test approach slips in. The approach should come from the Design-stage testing decision (recorded as the test card's strategySource); if it is improvised, say so and justify it against the risk. Prefer the lowest test level that proves the behavior; escalate to real-scenario only when user-visible or environment evidence is required.