Professional bug report pack

Worked example

(Scenario: ShopSphere checkout redesign, build 2.4.0-rc3 on https://staging.shopsphere.com, eight days before release. Three defects found executing the promo-code & checkout suite from Deliverable 2. Tickets shown as they'd appear in Jira, project key SHOP. Build, project key, and the SAVE20 code all come from the shared Capstone fixtures; the earlier 2.4.0-rc2 is referenced only by the Reopened bug below, which was marked fixed in rc2 and still fails in rc3.)

---

BUG 1 — SHOP-1487

Title: Promo code SAVE20 applies the 20% discount twice when re-applied after editing the cart

• Severity: High · Priority: High
• Status: Open (New) — filed, not yet assigned
• Component: Checkout / Promo code · Affects build: 2.4.0-rc3 · Found by: QA (executing TC-PROMO-09, recalculation-after-quantity-change)

Environment Desktop · macOS 14.5 · Chrome 125.0.6422.112 · staging 2.4.0-rc3 · guest checkout

Preconditions Guest checkout. Cart contains 1× "Aurora Desk Lamp" at $89.90. Promo SAVE20 (20% off order, valid, single-use intent) is active.

Steps to reproduce

1. Add the Aurora Desk Lamp ($89.90) to the cart and go to checkout as guest.
2. In the promo field, enter SAVE20 and click Apply — discount of −$17.98 shows; subtotal becomes $71.92. Correct so far.
3. Click Edit cart, change quantity to 2, return to checkout.
4. Observe the order summary without re-typing the code.

Expected result The 20% discount recalculates against the new subtotal once: subtotal $179.80, discount −$35.96, total $143.84.

Actual result The discount is applied twice: discount line shows −$71.92 against a $179.80 subtotal, total $107.88 — a $35.96 overcharge-in-customer's-favor. The promo summary lists SAVE20 twice.

Evidence

• promo-double-discount.png — order summary showing two SAVE20 lines and total $107.88.
• console-promo-recalc.txt — Console shows applyPromo() fired twice on the cart-edit return navigation; no error thrown, so this is silent.

Severity/Priority justification Severity High: it directly produces a wrong, money-losing total and is fully reproducible. Priority High: it's on the revenue path and trivial for a customer to trigger by editing their cart — must fix before release.

Notes / next in life cycle Single-bug ticket. Once a dev picks it up → Assigned → In Progress/Fixed; QA re-tests TC-PROMO-09 (the recalculation case this bug failed) plus a regression on TC-PROMO-01 (the normal single-apply case must still produce −$4.80, not be over-corrected by the fix) before Closed.

---

BUG 2 — SHOP-1492

Title: Checkout page errors out (500) and order can't be placed when promo field is submitted empty via Enter key

• Severity: Critical · Priority: High
• Status: Open (New) — flagged to dev lead in #checkout-release
• Component: Checkout / Promo code · Affects build: 2.4.0-rc3 · Found by: QA (executing TC-PROMO-06, empty-submission; reproduced via the Enter-key variant)

Environment Desktop · Windows 11 · Edge 125.0.2535.51 · staging 2.4.0-rc3 · logged-in account qa.buyer+1@shopsphere.test

Preconditions Logged-in user, one item in cart, on the checkout page with the promo field empty and focused.

Steps to reproduce

1. With the empty promo field focused, press Enter (do not type a code).
2. Observe the page.

Expected result Empty submit is ignored or shows an inline "Enter a promo code" hint; the checkout page stays usable and the order can still be placed.

Actual result The page reloads into a generic error screen ("Something went wrong"). The Place order button is gone; the cart is intact but checkout cannot be completed without a full browser refresh. Reproduced 3/3 times.

Evidence

• empty-promo-500.png — error screen replacing the checkout page.
• console-500-apply-promo.txt — Network tab: POST /api/v1/cart/cart_3b8e02/promo returns 500, request body { "code": "" }; Console: Uncaught (in promise) TypeError: cannot read 'discount' of undefined.

Severity/Priority justification Severity Critical: it blocks order completion — the core checkout function — and the empty-Enter path is something real users hit constantly. Priority High: blocker on the release-critical flow; nothing ships until this is fixed. (Note severity ≥ priority here; both top-tier.)

Notes / next in life cycle Root cause is server-side (empty code not validated), so the fix likely spans front-end guard + API. After Fixed, re-test the empty case (TC-PROMO-06, both click-Apply and Enter-key paths) and regression-test a valid code (TC-PROMO-01) and an invalid code (TC-PROMO-04) so the new guard didn't break normal apply or the existing "Invalid promo code" error.

---

BUG 3 — SHOP-1501

Title: Apple Pay button is unresponsive in guest checkout on iOS Safari — no sheet appears, no error

• Severity: High · Priority: Medium
• Status: Reopened — dev marked Fixed in 2.4.0-rc2; still reproduces on rc3
• Component: Checkout / Apple Pay · Affects build: 2.4.0-rc3 · Found by: QA (executing TC-PAY-01 on the guest path; re-test of SHOP-1455)

Environment Mobile · iPhone 13 · iOS 17.5.1 · Safari · staging 2.4.0-rc3 · guest checkout

Preconditions Guest checkout on iPhone Safari, cart with 1 item, on the payment step, a card provisioned in Apple Wallet, Apple Pay shown as a payment option.

Steps to reproduce

1. As a guest, reach the payment step on iPhone 13 / iOS 17.5.1 Safari.
2. Tap the Apple Pay button.
3. Wait ~5 seconds.

Expected result The native Apple Pay sheet slides up to confirm payment with Face ID / passcode.

Actual result Nothing happens — no sheet, no spinner, no error toast. The button registers the tap (brief highlight) but no payment sheet appears. Works correctly for logged-in users on the same device/build, so it's specific to the guest path. Reproduced 4/4 times.

Evidence

• applepay-guest-no-sheet.mp4 — screen recording of the tap with no sheet.
• safari-console-applepay.txt — remote-debug Console: ApplePaySession: must be created from a user gesture handler — the session is initialized after an async cart call instead of synchronously inside the tap handler, which Safari rejects in the guest flow.

Severity/Priority justification Severity High: a headline new payment method is entirely broken for a whole segment (guests, who are a launch focus). Priority Medium (not High) only because a working fallback exists — guests can still pay by card — and it's iOS-Safari-specific; if no card fallback existed this would be Priority High. Flag to PM for the go/no-go call (feeds Deliverable 5).

Notes / next in life cycle This was Reopened: it was marked Fixed in rc2 but re-test on rc3 shows it still fails, so the ticket goes back to the dev, not to Closed. When re-fixed, re-run TC-PAY-01 on the iOS Safari guest path and regression-check logged-in Apple Pay and the guest card path (TC-GUEST-01) so the gesture-handler change didn't regress the working paths. Note TC-PAY-01 is the plan's single Apple Pay smoke slice, so this one ticket carries the whole Apple Pay risk into the sign-off (Deliverable 5).

---

Why this pack is strong: three different kinds of defect (data error, blocker, platform-specific), each reduced to the minimum steps, each with concrete numbers and real console/network evidence, severity and priority set independently and justified, and one ticket correctly sitting in Reopened rather than New — showing command of the full bug life cycle, not just filing.