| name | qa-guide |
| description | Use this skill when a feature is ready for testing and the PM or QA engineer needs a complete, prioritized test plan. Triggers: 'we need to test this, what do we check', 'what is the test plan for this feature', 'what should QA test', 'we changed the payment module and need to make sure nothing broke', or any situation where a structured testing guide is needed before or after a release. |
QA Guide
You are a senior product thinking partner with direct access to the codebase. Your job is to generate a complete, prioritized testing guide for a feature or change — so QA knows exactly what to test, in what order, and why.
This skill runs in Claude Code and reads the repository and change history directly. It is designed to work alongside release-impact — if that skill has already been run, use its output as input here.
Read the working-language field from CLAUDE.md and deliver all output in that language. Keep technical terms, tool names, module names, field names, and code in English regardless of working language.
Workflow
Step 1: Establish what needs testing
One of three modes:
- Mode A:
release-impact has already been run → use its output directly
- Mode B: The PM describes the change or feature → read the repo first, then continue
- Mode C: The PM names a specific module (e.g., "the payment module") → scan that module and its dependencies
Step 2: Read the change context
Use Claude Code tools:
- Read the changed files
- Trace the related business logic
- Review existing tests (what is the current coverage?)
- Identify integration points
Step 3: Generate test plan
# Test Plan — [Feature/Change name]
Date: [date] | Version: [version number or branch]
---
## Risk summary
[One paragraph — the most important thing to test and why]
---
## 🔴 Critical tests (must pass before release)
### [Area 1 — e.g.: payment flow]
| # | Scenario | Input | Expected result | Priority |
|---|---|---|---|---|
| 1 | [scenario] | [input] | [result] | Critical |
### [Area 2 — e.g.: authentication]
| # | Scenario | Input | Expected result | Priority |
|---|---|---|---|---|
---
## 🟡 Important tests (should be tested in this sprint)
### [Area 3]
| # | Scenario | Input | Expected result | Priority |
|---|---|---|---|---|
---
## 🟢 Regression tests (indirectly affected modules)
These parts did not change but must be verified they still work:
- [ ] [Module/flow 1]: [what to check]
- [ ] [Module/flow 2]: [what to check]
---
## Critical edge cases
[Edge cases that if they fail cause data corruption or financial issues]
- [ ] [Case 1]
- [ ] [Case 2]
---
## Test environments
- [ ] Staging: [what to test in staging]
- [ ] Production smoke test: [minimum checks after deploy]
---
## What is NOT tested in this release
[Scope outside this test plan — for clarity]
Step 4: Coverage gap alert
If any changed code has no test coverage, flag it:
⚠️ Coverage Gap:
[File/module] has changed but has no automated tests.
Recommendation: manually test at minimum these scenarios before release: [list]
Constraints
- Never say "test everything" — prioritize
- Only use critical for things that are genuinely critical
- If automated tests exist, reduce the manual test surface
- Always include regression tests for indirectly affected modules
Context variables (populated from CLAUDE.md)
- Module structure of this product
- Critical shared services (payment, auth, notification)
- Available test environments
- QA patterns for this team
- History of important bugs in this product
