QE Story & Backlog Refinement

Use this when grooming a ticket, refining acceptance criteria, or doing a pre-sprint testability review — before the story is estimated or picked up. Not for release GO/NO-GO decisions, incident analysis, or writing test code.

Work through four phases, in order, in chat. Stop at each phase's stop-rule before moving on — don't jump straight to a scenario table without naming the risks first.

Input

Collect before starting:

FEATURE / TICKET:
<paste the story / acceptance criteria as written>

API / SYSTEM CONTEXT (optional): <endpoints, data model, service boundaries>
EXISTING COVERAGE (optional): <what's already tested, so you don't re-list it as a gap>
KNOWN RISKS (optional): <anything already flagged by the team>

If the ticket is thin (no AC, one-line description), don't guess — ask 2–3 finite, closed-form questions (multiple choice, not open-ended) before proceeding.

Phase A — Understand

Skim whatever code, handlers, or config exists for this feature — even a shallow pass beats guesswork. If you have no repo access, say so and proceed on the ticket text alone, labeling assumptions Assumed:.

Deliver in chat, briefly:

• 2 bullets — what the feature does and its critical flow
• Open questions for PM/dev if input was thin

Stop when: you could explain the flow to a teammate without re-reading the ticket.

Phase B — Gaps & risks

Plain language only — no generic advice.

Checklist:

• What happens on invalid input, timeouts, and retries?
• State changes after the main action (cart, session, async job)?
• Integration hand-offs — who owns the error?
• Anything already in existing coverage — don't re-list it as a gap.

Bad: "Test performance and security." Good: "If the promotions service times out on apply, checkout must not charge with a stale discount."

Stop when: you have 3–7 real risks, each with impact (P0–P2) and a one-line mitigation.

Phase C — Scenarios (max 5)

A short table, not a report appendix:

#	What to try	Why it matters
1	…	…

• Mix scriptable checks with exploratory sessions (vary order, concurrency, config).
• Tie each row to a real code path when you have one; otherwise label Assumed:.
• Focus on the AC gaps the ticket should close — not general regression coverage.

Stop when: a junior tester could run the table without reading the whole codebase.

Phase D — Refinement decisions

• List missing acceptance criteria (max 5) — behavior, errors, limits, integrations.
• Suggest 2–3 AC improvements, in plain language the team can paste directly into the ticket.
• Flag anything marked Assumed: that would block development or test design if left unresolved.

Stop when: the user could update the ticket without guessing at edge cases.

---

Worked example

Ticket: "As a shopper, when I click 'Save for later' on a cart line item, that item moves from my active cart to a 'Saved for later' list on the same page, without affecting other cart items or the order total. AC: item removed from cart, added to saved list, cart total recalculates, saved list persists across page reload. Reverse action 'Move to cart' also exists."

Context given: POST /cart/items/{id}/save-for-later moves the item server-side; cart and saved-list are separate collections on the same Order/Cart aggregate, keyed by session or user id. Unit tests exist for cart total recalculation; none yet for the save-for-later endpoint or UI. Known risk: unclear if saved items retain applied promo/quantity discounts when moved back.

Phase A

• The click triggers a server-side move (POST /cart/items/{id}/save-for-later) from the cart collection to a saved-items collection on the same aggregate; cart total recalculates and the saved list persists via session/user id.
• Open questions: Does a promo applied to the item survive a round trip through "saved"? Can the last/only item in the cart be saved (empty-cart state)? What happens on concurrent save requests from two tabs?

Phase B — gaps & risks

1. [P1] Promo/discount reapplication on "Move to cart" is undefined. Assumed: promo is dropped and must be manually reapplied. Mitigation: confirm with PM, write explicit AC.
2. [P1] Endpoint failure mid-request (network drop after cart removal, before saved-list write) could lose the item from both lists. Mitigation: verify the move is transactional/idempotent.
3. [P2] Concurrent edits — item saved in one tab while quantity changes in another. Mitigation: check optimistic-locking behavior.
4. [P2] Guest sessions: saved list is session-keyed — expiry mid-visit could silently drop items, contradicting "persists across page reload." Mitigation: confirm session TTL and behavior on expiry.
5. [P1] UI must not show a stale total between item removal and recalculation. Mitigation: confirm recalculation is synchronous with the save action.

Phase C — scenarios

#	What to try	Why it matters
1	Save an item with an active promo, then move it back to cart	Exposes undefined promo-reapplication behavior (P1)
2	Save the only item in the cart	Empty-cart transition, easy to miss in AC
3	Start save-for-later, kill network mid-request	Tests data-loss risk if the move isn't transactional (P1)
4	Save as a guest, close browser, reopen after session TTL	Tests the "persists across reload" claim against actual session-based storage
5	Save/un-save the same item rapidly from two tabs	Exploratory — concurrency/idempotency of the endpoint

Phase D — refinement decisions

Missing AC:

1. Promo/discount behavior on cart → saved → cart is unspecified.
2. No AC for guest-session persistence duration or expiry behavior.
3. No AC for saving the last/only cart item.
4. No AC for concurrent or duplicate save requests.
5. No AC for partial-failure behavior on the move (data-loss risk).

Suggested AC improvements:

• "When an item with an active promo moves to Saved for later and back, the promo is re-evaluated against current cart contents — not silently retained."
• "If the save-for-later request fails after removing the item from the cart, the item is restored to the cart; the move is transactional."
• "Saved items for guest sessions persist for [X] or until session expiry (team to decide); expiry behavior is explicit in the ticket, not left to implementation."

Blocking assumptions: promo-drop behavior and endpoint transactionality both need confirmation before test design can proceed with confidence.

---

Adapted from @qe-craft/mcp (npm), refinement mode, source version 1.0.1 / prompt version intel-v1-coach. This is a static snapshot — the live tool composes this per-run and adds repo-aware exploration hints; see https://www.npmjs.com/package/@qe-craft/mcp for the dynamic MCP version.