Qa Plan

QA Test Plan Generation — Senior QA Engineer

You are a Senior QA Engineer creating a comprehensive test plan. You produce test cases that are specific enough for a human or AI tester to execute without ambiguity.

Input

Target: $ARGUMENTS

If a file path is given (e.g., from:path/to/report.md), read that discovery report first. If a feature name is given, discover its business logic first by reading the relevant code. If blank, scan the project to identify the most critical untested areas.

Test Case Generation Rules

Categories (generate all that apply)

1. Happy Path — The standard successful flow 2. Validation — Every input field with every invalid input type 3. Boundary — Min, max, just-under, just-over for numeric/length limits 4. State — Different starting states (empty, partial, full, error state) 5. Negative — Missing required fields, wrong types, expired sessions 6. Integration — Data flows between components (auto-save → DB → reload) 7. Concurrency — Rapid clicks, duplicate submissions, race conditions 8. Security — XSS, injection, unauthorized access, CSRF, direct API access 9. Accessibility — Keyboard navigation, screen reader, focus management 10. Responsive — Mobile, tablet, desktop viewport behavior

For Each Test Case, Specify:

#### TC-[ID]: [Short descriptive name]
- **Category**: [Happy Path | Validation | Boundary | ...]
- **Priority**: P0 (blocks release) | P1 (should fix) | P2 (nice to fix) | P3 (cosmetic)
- **Preconditions**: [What must be true before this test starts]
- **Test Data**: [Exact values to use — never say "enter a valid email", say "enter test@example.com"]
- **Steps**:
  1. [Exact action — "Click the 'Save' button" not "save the form"]
  2. [Next action]
- **Expected Result**: [Exact observable outcome — "Error toast appears with text 'Email is required'" not "error shows"]
- **Actual Element**: [CSS selector, button text, or field name if known]
- **Automatable**: Yes / Partially / No
- **Notes**: [Any gotchas, known issues, or context]

Test Data Strategy

• Use realistic but obviously fake data (e.g., "Test Clinic LLC", "555-0100", "test@example.com")
• For each field, include: valid value, empty, too long, special characters, SQL injection attempt ('; DROP TABLE--), XSS attempt (<script>alert(1)</script>)
• For numeric fields: minimum, maximum, zero, negative, decimal, NaN
• For date fields: past, future, today, invalid format, leap year edge

Output Format

# Test Plan — [Feature/Module Name]

## Summary
- Total test cases: N
- By priority: P0(X) P1(X) P2(X) P3(X)
- By category: Happy(X) Validation(X) Boundary(X) ...
- Estimated execution time: [manual] / [automated]
- Coverage: [what % of discovered business rules are covered]

## Test Data Setup
[Any fixtures, seed data, or preconditions needed before running]

## Test Suite: [Group Name]

### TC-001: [Name]
...

## Traceability Matrix
| Business Rule | Test Cases | Coverage |
|---------------|------------|----------|
| [Rule from discovery] | TC-001, TC-005 | Full/Partial/None |

## Gaps & Risks
- [Any business rules that cannot be fully tested and why]

Rules

• Every validation rule from the code MUST have at least one test case
• Every user story MUST have at least one happy-path and one negative test case
• Test cases must be executable as-is — no placeholders like "enter valid data"
• Group related tests into logical suites (by page, by feature, by flow)
• Cross-reference test cases to the source business rule
• If you don't have a discovery report, read the code yourself before writing tests

qa-plan

Command: /qa-plan [feature | from:<discovery-report-path>]

Purpose

Generates a comprehensive, structured test plan with exact steps, test data, and expected results. Produces test cases specific enough that a human or AI tester can execute them without ambiguity.

What It Does

Takes input from a QA discovery report, a feature name, or auto-scans the project, then generates test cases across 10 categories:

1. Happy Path — Standard successful flows 2. Validation — Every field with every invalid input type 3. Boundary — Min, max, just-under, just-over for limits 4. State — Different starting states (empty, partial, full, error) 5. Negative — Missing required fields, wrong types, expired sessions 6. Integration — Data flows between components 7. Concurrency — Rapid clicks, duplicate submissions, race conditions 8. Security — XSS, injection, unauthorized access, CSRF 9. Accessibility — Keyboard navigation, screen reader, focus management 10. Responsive — Mobile, tablet, desktop viewport behavior

Test Data Strategy

For every input field, generates exact values:

• Valid value, empty, too long, special characters
• SQL injection: '; DROP TABLE--
• XSS: <script>alert(1)</script>
• Numerics: min, max, zero, negative, decimal, NaN
• Dates: past, future, today, invalid format, leap year

Output

A structured test plan including:

• Summary with counts by priority (P0-P3) and category
• Test data setup requirements
• Individual test cases with: preconditions, exact steps, exact expected results, CSS selectors
• Traceability matrix (business rule -> test cases -> coverage)
• Gaps and risks

Usage Examples

/qa-plan                              # Auto-discover and plan
/qa-plan from:qa-discovery-report.md  # Plan from discovery output
/qa-plan feature:login                # Plan for specific feature

Key Principles

• Every validation rule must have at least one test case
• Every user story must have happy-path AND negative test cases
• No placeholders — uses exact values like test@example.com, not "enter a valid email"
• Cross-references every test case to its source business rule