Qa Handoff Package

---
name: qa-handoff-package
description: "Turn a story and its change into a clean 'ready for QA' package — test scenarios, edge cases, the data and environment setup, and what's explicitly out of scope. Use when asked to prep a QA handoff, what should QA test here, write test scenarios for this story, or make this ready for QA. Produces the scenarios mapped to acceptance criteria, the edge/negative cases devs forget, the exact data and environment setup to reproduce, the risk areas to probe, and the out-of-scope list so QA doesn't chase the wrong things."
---

# QA Handoff Package

The "ready for QA" that isn't — a story tossed over the wall with no test data, no edge cases, and no idea what changed — is how bugs slip and QA burns a day setting up. This turns the story and its change into a real handoff: scenarios tied to the acceptance criteria, the negative and edge cases developers reliably forget, the exact data/environment to reproduce, and a clear line around what's *not* in scope, so testing is focused, not archaeology.

## What This Skill Produces

- **Test scenarios mapped to acceptance criteria** — every AC has at least one way to verify it
- **Edge & negative cases** — empty/boundary/invalid inputs, permissions, concurrency, the forgotten paths
- **Data & environment setup** — the exact accounts, feature flags, seed data, and env needed to reproduce
- **Risk areas to probe** — where this change is most likely to have broken something (incl. nearby regressions)
- **Out of scope** — what QA should *not* spend time on for this change

## Required Inputs

Ask for these if not provided:
- **The story & acceptance criteria** — what it's meant to do
- **The change** — what was built (a summary or the MR/PR diff), so scenarios match reality
- **Environments & data** — where QA tests, and what setup/flags/accounts are needed
- **Known risk/complexity** — anything the dev is worried about, or areas the change touches indirectly

## Framework: A Handoff QA Can Run

1. **Cover every AC.** Each acceptance criterion gets a concrete scenario — no AC left unverified.
2. **The happy path is the easy 30%.** The value is the edge and negative cases: empty, max, invalid, unauthorised, offline, concurrent, mid-migration.
3. **Reproducibility is setup.** Name the exact data, accounts, roles, and flags — "test it" without setup wastes QA's morning.
4. **Point at the risk.** Where the diff touches shared code or a fragile area, call it out — including regressions in neighbouring features.
5. **Bound it.** State what's out of scope so QA doesn't test the whole app for a small change.
6. **Ground in the actual change.** Scenarios match what was built, not what the story wished for.

## Output Format

### QA Handoff — [story] · build: [MR/PR ref]

### Scenarios (by acceptance criterion)
| AC | Scenario | Expected |
|---|---|---|

### Edge & negative cases
- [empty / boundary / invalid / permission / concurrency / offline …]

### Setup to reproduce
- Environment: … · Accounts/roles: … · Feature flags: … · Seed data: …

### Risk areas / possible regressions
- [where this change might have broken something nearby].

### Out of scope
- [what not to test for this change].

## Quality Checks
- [ ] Every acceptance criterion has at least one scenario
- [ ] Edge and negative cases are included, not just the happy path
- [ ] Exact data/environment/flag setup is specified for reproducibility
- [ ] Risk areas and possible regressions are called out
- [ ] An explicit out-of-scope list bounds the testing
- [ ] Scenarios reflect what was actually built, not just the story text

## Anti-Patterns
- **Happy-path only** — the bugs live in the edges.
- **"Just test the story"** with no data/environment setup — a lost QA morning.
- **No scope boundary** — QA re-tests the whole app for a one-line change.
- **Ignoring regressions** in features the change touches indirectly.
- **Scenarios from the story, not the build** — testing what was wished, not what shipped.

## Example Trigger Phrases
- "Prep a QA handoff for this story and its MR."
- "What should QA test here, including edge cases and setup?"
- "Write test scenarios mapped to these acceptance criteria."
- "Make this ready for QA — what's in and out of scope?"