Test-case suite for the promo-code & checkout flow

What you'll produce

A structured suite of 12–15 test cases for ShopSphere's new checkout-and-promo-code flow — each with a stable ID, a clear title, preconditions, exact numbered steps, and a single observable expected result — covering the happy path, edge cases, and error/negative cases. This is the executable spec a tester re-runs every release: it turns the requirements spec into repeatable checks, lets anyone on the team get the same result you do, and produces an auditable record of exactly what was verified before sign-off. It's the artifact that distinguishes a real QA engineer from someone who "clicks around" — and the one a hiring manager will read most closely in your portfolio, because it shows whether you can think systematically about coverage instead of only testing the happy path. You'll format it as it would live in TestRail or a shared spreadsheet, so it drops straight into a real team's workflow.

Instructions

1. Anchor to the spec and to Deliverable 1. Pull the in-scope items from your test plan: the promo-code field, cart subtotal / quantity, guest checkout, Apple Pay, and order placement. You'll write cases against these — not against random screens. If your plan marked Apple Pay as a thin smoke-only slice, keep it to one or two cases here.
2. Reuse the canonical test data, don't invent your own. The promo codes and their rules are fixed in the Capstone fixtures so every deliverable agrees: SAVE20 = 20% off, min cart $20.00, multi-use; WELCOME15 = $15.00 off, single-use per account, min cart $50.00; SUMMER19 = expired 2026-05-31; SUMMER20 = case-insensitive alias of SAVE20. Restate them in a short Test data block at the top of your suite so a reviewer can reproduce every case without leaving the document.
3. Choose a fixed column structure and keep it identical for every case: ID · Title · Type (Positive / Negative / Edge) · Priority (P1–P3) · Preconditions · Steps (numbered) · Expected result. Consistency is what makes a suite feel like a paid product.
4. Write IDs that sort and group, e.g. TC-PROMO-01, TC-CART-03, TC-GUEST-01, TC-PAY-01. A tester scanning the run should know the feature area from the ID alone.
5. Cover the three buckets deliberately, not by accident:
   • Happy path (positive): valid code applies correct discount; order totals update; guest checkout completes; Apple Pay path succeeds.
   • Edge cases: minimum-cart boundary (just below vs. just at the threshold), case-insensitivity, applying then removing a code, re-applying a single-use code, recalculation when cart quantity changes after a code is applied.
   • Error / negative cases: invalid code, expired code, empty submission, leading/trailing whitespace, attempting two codes, a code below the minimum cart value.
6. Write atomic steps and a single, observable expected result. Each step is one action ("4. Enter SAVE20 in the Promo code field and click Apply."). The expected result must be something a tester can see — an exact amount, an exact error string, a specific UI state — not "it works." Prefer real numbers: a $48.00 subtotal with SAVE20 becomes $38.40, not "discount applied."
7. Pin every expected money value to the math so the case is falsifiable. State the subtotal, the discount, and the resulting total explicitly; that's what lets the case catch a rounding or off-by-one bug instead of waving at it.
8. Make negative cases specify the exact failure, including the message text and that nothing partially applies (no discount, no charge, cart unchanged). "Shows an error" is not gradeable; "Shows inline error 'This code has expired' and the order total is unchanged at $62.00" is.
9. Add a priority to each case (P1 = blocks release if it fails, e.g. wrong discount math or a code that lets a free order through; P3 = cosmetic) so the suite doubles as a run order under time pressure.
10. Self-review for the traps: every case independently runnable from its preconditions, no two cases that are secretly the same equivalence class, at least one boundary pair, and at least one case proving a security-relevant rule (single-use enforcement or stacking prevention). Then format the whole thing as a clean table.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

• Structure & runnability of each case — 1: missing IDs, preconditions, or expected results; steps too vague to follow · 2: every case has ID, title, preconditions, numbered atomic steps, and one expected result · 3: consistent columns, stable grouped IDs, shared documented test data, and each case is independently runnable from its preconditions by anyone.
• Coverage across happy / edge / negative — 1: mostly happy-path; few or no negative cases · 2: 12–15 cases spanning all three buckets across the in-scope areas · 3: each bucket is deliberate and non-redundant — includes a boundary pair, case-insensitivity, recalculation-after-change, and security-relevant rules (single-use, no-stacking).
• Falsifiable expected results — 1: "it works" / "shows an error" with no specifics · 2: concrete states and amounts given · 3: every money value pinned to explicit math (subtotal → discount → total) and every error names the exact message and confirms nothing partially applies — so each case can actually catch a bug.
• Prioritization & QA judgment — 1: no priorities, or priorities don't reflect risk · 2: each case carries a sensible P1–P3 · 3: priorities map to release risk (discount-math and redemption-abuse cases are P1, cosmetics P3) and the suite reads as a defensible run order under deadline.
• Coherence with the test plan (Deliverable 1) — 1: tests areas the plan excluded or ignores its priorities · 2: scope matches the plan · 3: clearly traces from the plan's in-scope items and risk ranking (e.g., Apple Pay kept to the plan's thin smoke slice), forming one continuous QA story.