Test plan template
Test cases come straight from a story's acceptance criteria: at least one per criterion, plus the negative and edge cases from the PRD and UX spec. When something fails, the bug report says exactly how to see it.
Templates · Test plan template
Template 8 of 10
- Signed off by:
- QA
- Comes after:
- Readiness check
- Leads to:
- Change request
BO-3.md
## Test cases | # | AC | Steps | Expected | Data | |---|---|---|---|---| --- # <KEY>-<n> · Bug: <what's wrong, in one line> **Status:** Ready · **Owner:** <the story's owner> · **Points:** 1 · **Epic:** <the story's epic> ## Found in <story key>, while testing <which criterion>. Severity: high/medium/low. Found by <name>. Environment: <where>. ## Steps ## Expected ## Actual ## Evidence
Test cases
- At least one per acceptance criterion. Number the criterion it tests in the AC column, so a failed case points straight at what isn't done.
- Then the negative and edge cases. Empty input, the limit and one past it, a file in the wrong format, two people doing the same thing at once. The PRD's non-functional requirements and the UX spec's error states are where to look.
- Data. Say exactly what to test with: the file, the account, the product. A case someone else can't run isn't a test.
Regression scope
When a change touches existing behaviour, list the stories and flows it affects and the cases to run again.
Bug reports
A bug is a story, so it shows on the board and someone owns it. The title says what's wrong in one line. Steps are numbered and start from somewhere anyone can reach. Expected cites the acceptance criterion or requirement; Actual says what happened instead. Attach the evidence: a screenshot, the file, the error.
Put high-severity bugs, or ones that block their story, in the running sprint and tell the story's owner.
Common mistakes
- Testing only the criteria, not the edges.
- "Doesn't work" bugs with no steps.
- Passing a story with a known failing case "because it's minor". Raise it as a bug instead.
Example
Test cases · BO-3
| # | AC | Steps | Expected | Data |
|---|---|---|---|---|
| 1 | 1 | Upload the sheet | 14 unmatched rows listed first, each with up to 3 suggestions | sheet-212.xlsx |
| 2 | 2 | Pick the first suggestion on row 7 | Row 7 moves to matched | sheet-212.xlsx |
| 3 | 4 | Leave one row unmatched | Add to cart disabled: "1 row needs you" | sheet-212.xlsx |
| 4 | 5 | Type SKU 4471-B on row 9 | "No product with SKU 4471-B" | sheet-212.xlsx |
| 5 | – | Upload a 0-row sheet | "That sheet has no rows" | empty.csv |
BO-9 · Bug: dropped rows come back after a page reload
Status: Ready · Owner: Priya · Points: 1 · Epic: BO-1
Found in
BO-3, while testing criterion 3. Severity: high. Found by Mai. Environment: staging.
Steps
- Upload sheet-212.xlsx. 2. Drop row 4. 3. Reload the page.
Expected
Row 4 stays dropped (BO-3, criterion 3).
Actual
Row 4 is back in the list as unmatched.
Have Releavo write the test plan
In Releavo this lives at tests/BO-3.md. Releavo drafts it from the docs before it and your team's conversations; every edit is a draft until QA approves it, and approved versions are never overwritten.