QA Test Plan
Quick start
Read the feature description, identify the user-facing behaviors in scope, then output one markdown table per group: Functional, Negative, Error / Failure, Edge cases (and Non-functional when relevant). Each case is one row with ID, Title, Preconditions, Steps, Expected, Priority.
Example
Functional
| ID |
Title |
Preconditions |
Steps |
Expected |
Priority |
| TC-01 |
Login — valid creds |
User exists |
1. Open /login2. Enter email3. Enter password4. Submit |
Redirect to /dashboard |
P0 |
Negative
| ID |
Title |
Preconditions |
Steps |
Expected |
Priority |
| TC-02 |
Login — wrong password |
User exists |
1. Open /login2. Enter email3. Enter wrong password4. Submit |
Inline error shown, stays on /login |
P1 |
When To Use
- The user asks for a test plan, test cases, QA coverage, or "how would you test this"
- Planning verification for a new feature, before or after implementation
- Reviewing whether a feature is testable or has coverage gaps
When Not To Use
- The user wants automated test code — go write the tests directly
- Exploratory testing charters — different artifact
- Verifying a single bug fix where one repro step is enough
- Pure unit-test design for an internal function
Core Rules
- Steps are user-visible actions ("Submit the form", "Open /login"), never selectors, fixtures, or framework code.
- Expected results are observable outcomes (URL, visible text, state the user can see), never internal state.
- One assertion focus per case — split when a case verifies two unrelated things.
- Default coverage per behavior: happy path + key negatives + 1–2 edge cases. Stop when extra cases stop reducing risk.
- Consider error scenarios for every flow with user-visible consequence (submit, save, payment, async). If the flow is read-only with a trivial loading state, write
no error cases — read-only instead of silently skipping.
- One case per failure mode, not per HTTP code. "Save fails — error toast shown, form remains editable, no data loss" covers a class.
- Group cases by user-facing area, not by technical layer.
- Priority: P0 blocks release / core path, P1 important non-blocking, P2 nice-to-have / rare.
- Describe inputs by kind, not literal values. "Enter a valid email" — not
a@b.com. "Enter text one character over the limit" — not "Enter 501 chars". Specific values belong in fixtures or are picked by the tester at execution time.
Workflows
- Read the feature description and list the user-facing behaviors in scope.
- Note ambiguities in a short "Open questions / assumptions" block — do not silently guess.
- For each behavior, draft cases in this order: happy path → negatives → error scenarios (or
no error cases — read-only) → edge cases.
- Assign priority per case.
- Output grouped markdown tables: Functional · Negative · Error / Failure · Edge cases · Non-functional (when relevant).
- End with "Open questions / assumptions" if any remain.
Advanced features
See REFERENCE.md for the priority rubric, step-writing do/don't, coverage heuristics, and a longer worked example.
Red Flags
- Steps that mention CSS selectors, data-testids, or framework APIs
- Steps with literal data values baked in (specific emails, magic strings, hard-coded numbers) instead of described by kind
- Expected results phrased as internal state ("the
isLoggedIn flag is true")
- A case that asserts two unrelated outcomes
- Missing negatives on a form or auth-gated action
- Error / Failure section omitted on a write/save/payment flow with no
no error cases note
- Every case marked P0
1---2name: qa-test-plan3description: Produces a structured QA test plan from a feature description. Cases are written in a behavioral style — concrete enough to execute manually, neutral enough to map to automated E2E later. Use when the user asks for a test plan, test cases, or QA coverage for a feature.4---56# QA Test Plan78## Quick start910Read the feature description, identify the user-facing behaviors in scope, then output one markdown table per group: Functional, Negative, Error / Failure, Edge cases (and Non-functional when relevant). Each case is one row with ID, Title, Preconditions, Steps, Expected, Priority.1112## Example1314### Functional15| ID | Title | Preconditions | Steps | Expected | Priority |16|----|-------|---------------|-------|----------|----------|17| TC-01 | Login — valid creds | User exists | 1. Open /login<br>2. Enter email<br>3. Enter password<br>4. Submit | Redirect to /dashboard | P0 |1819### Negative20| ID | Title | Preconditions | Steps | Expected | Priority |21|----|-------|---------------|-------|----------|----------|22| TC-02 | Login — wrong password | User exists | 1. Open /login<br>2. Enter email<br>3. Enter wrong password<br>4. Submit | Inline error shown, stays on /login | P1 |2324## When To Use2526- The user asks for a test plan, test cases, QA coverage, or "how would you test this"27- Planning verification for a new feature, before or after implementation28- Reviewing whether a feature is testable or has coverage gaps2930## When Not To Use3132- The user wants automated test code — go write the tests directly33- Exploratory testing charters — different artifact34- Verifying a single bug fix where one repro step is enough35- Pure unit-test design for an internal function3637## Core Rules38391. Steps are user-visible actions ("Submit the form", "Open /login"), never selectors, fixtures, or framework code.402. Expected results are observable outcomes (URL, visible text, state the user can see), never internal state.413. One assertion focus per case — split when a case verifies two unrelated things.424. Default coverage per behavior: happy path + key negatives + 1–2 edge cases. Stop when extra cases stop reducing risk.435. Consider error scenarios for every flow with user-visible consequence (submit, save, payment, async). If the flow is read-only with a trivial loading state, write `no error cases — read-only` instead of silently skipping.446. One case per failure mode, not per HTTP code. "Save fails — error toast shown, form remains editable, no data loss" covers a class.457. Group cases by user-facing area, not by technical layer.468. Priority: P0 blocks release / core path, P1 important non-blocking, P2 nice-to-have / rare.479. Describe inputs by *kind*, not literal values. "Enter a valid email" — not `a@b.com`. "Enter text one character over the limit" — not "Enter 501 chars". Specific values belong in fixtures or are picked by the tester at execution time.4849## Workflows50511. Read the feature description and list the user-facing behaviors in scope.522. Note ambiguities in a short "Open questions / assumptions" block — do not silently guess.533. For each behavior, draft cases in this order: happy path → negatives → error scenarios (or `no error cases — read-only`) → edge cases.544. Assign priority per case.555. Output grouped markdown tables: Functional · Negative · Error / Failure · Edge cases · Non-functional (when relevant).566. End with "Open questions / assumptions" if any remain.5758## Advanced features5960See [REFERENCE.md](REFERENCE.md) for the priority rubric, step-writing do/don't, coverage heuristics, and a longer worked example.6162## Red Flags6364- Steps that mention CSS selectors, data-testids, or framework APIs65- Steps with literal data values baked in (specific emails, magic strings, hard-coded numbers) instead of described by kind66- Expected results phrased as internal state ("the `isLoggedIn` flag is true")67- A case that asserts two unrelated outcomes68- Missing negatives on a form or auth-gated action69- Error / Failure section omitted on a write/save/payment flow with no `no error cases` note70- Every case marked P0
geril07