Test plan

Use after user stories are defined and before development or testing begins, to turn a feature into a plan someone else can execute.

## Definitions

Use these meanings consistently in every step.

- **Feature:** The feature record being tested, or the feature whose record link the user pasted into the chat
- **Scenario:** One condition being tested, written so a person who did not define the feature can run it and judge the result
- **Coverage areas:** The primary path, alternate paths, edge cases, permissions, empty and error states, and regression risk on existing behavior

## Workflow

1. Read the feature, its requirements, and its acceptance criteria. When acceptance criteria exist, every one of them becomes at least one scenario.
2. Confirm scope with the user: which devices, which browsers, and whether the coverage is manual, automated, or both
3. Map the coverage areas. Start with the primary path, then alternate paths, then the boundaries.
4. Write each scenario with preconditions, steps, and an expected result. The expected result is specific enough to be judged right or wrong without interpretation.
5. Cover permissions explicitly. State what an owner, a contributor, a reviewer, and a viewer each see and can do.
6. Cover empty states, partial data, and error handling. These are where most defects survive to release.
7. Identify regression risk. Name the existing behavior this change could break and add scenarios for it.
8. Note what is deliberately out of scope so a gap is not read as an oversight

## Rules

- If the feature or its requirements are missing, ask short follow-up questions before drafting
- Every acceptance criterion maps to at least one scenario
- Expected results are specific. "Works correctly" is not an expected result.
- Cover the permission levels the feature is exposed to rather than assuming a single role
- Reference the feature and its requirements by reference number and name
- Do not create to-dos or update the record. Present the plan and let the user apply it.
- Headers use sentence case. No em dashes, en dashes, or curly quotes.

## Output

```
## Scope  
<what is covered, on which devices and browsers>  
  
## Scenarios  
| ID | Area | Preconditions | Steps | Expected result |  
  
## Permissions  
| Role | Can see | Can do |  
  
## Regression risk  
- <existing behavior at risk, and the scenario that covers it>  
  
## Out of scope  
- <what is not covered and why>
```

## Quality checks

- Every acceptance criterion maps to at least one scenario
- Every expected result can be judged right or wrong without interpretation
- Empty, partial, and error states each have coverage
- Permissions are covered for every role the feature is exposed to