Phase 2 - Planning

Planning is where you define the scope, objectives, and strategy for the current test cycle. Everything produced here becomes the input contract for Phase 3 (Design) and Phase 4 (Execution) - no design or execution skill will run a domain that is not in the plan.

---

Skills in this phase

Skill	When to use	Purpose
/qa-requirement	First cycle	Gather and structure requirements from scratch
/qa-plan	Every cycle	Derive the test strategy from requirements
/qa-impact	Subsequent cycles	Track requirement changes and flag what needs re-running

---

Step 1 - Gather requirements

First cycle: Run /qa-requirement to capture what needs to be tested.

You can provide requirements in three ways:

• Paste Jira ticket URLs (read via MCP if available)
• Paste raw requirement text directly into chat
• Answer the guided questionnaire interactively

Output - requirements/ folder:

requirements/
  requirements-shared.md    - cross-domain context (environment, scope, risks)
  requirements-ui.md        - UI-specific requirements
  requirements-api.md       - API-specific requirements
  requirements-a11y.md      - accessibility requirements
  requirements-perf.md      - performance requirements

Files use dated sections so history is preserved across cycles.

Subsequent cycles: Use /qa-impact instead. It diffs the new requirements against the previous cycle, updates only the changed files, and flags which domains need re-running.

---

Step 2 - Create the test plan (/qa-plan)

Run /qa-plan after requirements exist. It reads every requirements/*.md file and dq-qa.config.json, then writes qa-plan.md.

What the plan contains:

Section	Description
Cycle scope	Which domains are in scope and why
Out of scope	Explicitly excluded domains with rationale
Test objectives	What this cycle must prove
Risk register	Identified risks with likelihood, impact, and mitigation
Domain plans	Per-domain test approach and endpoint/flow targets
Entry/exit criteria	What constitutes pass and fail for the cycle

Example plan structure:

## 2026-05-26

### Cycle scope
Domains in scope: API, Accessibility

### Risk register
| Risk | Likelihood | Impact | Mitigation |
| Auth token race condition | Medium | High | Include refresh edge cases |

### Domain plans
#### API
- Test /auth/login, /auth/refresh, /auth/logout

---

Step 3 - Impact analysis (subsequent cycles)

When requirements change mid-sprint or at the start of a new cycle, run /qa-impact instead of /qa-requirement + /qa-plan. It:

1. Reads the new requirements
2. Diffs against the previous cycle's requirements/*.md files
3. Updates only the changed sections (history preserved)
4. Appends a dated section to qa-plan.md with re-run flags

Re-run analysis output:

| Domain        | Re-run needed? | Reason                         |
| API           | Yes            | New /payments endpoint added   |
| UI            | Yes            | Login page redesigned          |
| Accessibility | Yes            | Login page redesigned          |
| Performance   | No             | No load-affecting changes      |

---

Phase gate

Phase 2 is complete when:

• [x] requirements/ folder contains at least requirements-shared.md
• [x] qa-plan.md exists with a current dated section
• [x] At least one domain is listed as in scope

Once the plan exists, proceed to Phase 3 - Design.