🟠 E-commerce QA

Model answer

I'd map the funnel and test each transition plus the state carried forward. Cart: add, update quantity, remove, and an out-of-stock item appearing at checkout. Address: validation, required fields, an unsupported shipping region. Shipping: rate selection and the total updating correctly. Payment: a valid sandbox card, a decline, a 3DS challenge, and a gateway timeout. Confirmation: order created once, confirmation email sent, correct totals. Then the guest-specific cases: there's no saved data so I check the email-only identity, the order-lookup token can't be guessed, and if the guest later registers with the same email the past order associates to the new account. I'd also cover session expiry mid-funnel and back-button re-submission. The point is the funnel carries state between steps, so I assert it stays consistent end to end, and the guest path diverges from the logged-in path at identity and persistence.

Model answer

I'd cover the categories separately because they behave differently: a valid unused code applies the right discount; an expired code is rejected with an expiry-specific message; a single-use code already redeemed is rejected as used; a malformed/unknown code is rejected as invalid; and a code that doesn't meet its minimum-spend or product condition is rejected with that reason. For each valid application I assert the cart total recalculates server-side, not just visually. Then the interaction cases: applying a second code (stacking), removing the discounted item after applying a code, and re-applying after removal. I'd add a rate limit / brute-force check on the validation endpoint so codes can't be enumerated. The signal is that 'invalid' is several distinct states, and the total is always the server's number.

Model answer

The defect only appears under true parallelism, so I'd seed a product with stock = 1 and fire two add-to-cart-and-purchase requests simultaneously — at the API level, with controlled timing — rather than clicking through two browsers one after another. The assertion is exactly one confirmed order and one explicit out-of-stock failure, with the final stock at zero, never negative, and no orphaned order row. I'd repeat the race many times because it's probabilistic, and I'd test the variants: both add to cart but only one pays, both reach payment, and a reservation timing window where stock is held during checkout and released on abandonment. I'd automate this as a concurrency test in CI against seeded stock, never against live inventory. Underneath, I'm checking whether the write is serialised — a row lock or atomic decrement — so the answer is really about how the system protects shared mutable state.

Model answer

I'd build a small matrix of coupon combinations and run them against deliberately low-value carts where the floor is reachable: a 90%-off plus free-shipping on a $5 order, two percentage codes, a fixed-amount code larger than the subtotal. For each I assert the total stops at the defined floor (typically not below zero, often not below cost) and that the order can't complete at $0.00 without a payment step. I'd confirm the total is recomputed on the server, ignoring any client-submitted price, so request tampering can't force a lower amount. I'd test the stacking rules themselves: if only one code is allowed, a second is rejected; if N stack, the N+1th is refused. And the orphan case — apply a code, then remove the qualifying item — the discount must clear. Pairwise generation keeps the combination count manageable. The domain signal is that discounts interact, so the test target is the interaction and its floor, not the individual code.

Model answer

This is a cart-vs-checkout divergence test. I'd add an item to the cart at price A, change the price to B via the admin path, then continue to checkout without refreshing so the client still holds A. The assertion is that the server recalculates at confirm time and the customer pays the authoritative current price — and critically that a price increase is shown to the customer before payment is taken, not applied silently. I'd test both directions: a drop (customer should benefit or at least see the lower price) and a rise (must not be charged more than they agreed without acknowledgement). I'd add the tampering case — submitting a forged lower price in the request — and assert the server ignores it. I'd also cover a stale cart reopened days later where the item is now out of stock or discontinued. The principle is that the client cart is a convenience, the server price is the truth, and any divergence must be reconciled visibly before charging.

Model answer

I'd separate the three phases — authorise, capture, webhook confirmation — and inject failure into each with a gateway stub like WireMock so I control timing deterministically. The headline scenario: submit payment, let authorisation succeed, then drop or delay the confirmation webhook. The assertion is that no order is left in the confirmed state and inventory isn't permanently decremented for an unconfirmed sale — the order sits in an explicit pending state and the customer gets a clear message, not a blank page or a false success. I'd test the reconciliation path: when the webhook finally arrives late, the pending order resolves correctly and doesn't double-process. I'd also cover a network timeout on submit where the client doesn't know if it went through, and assert an idempotent retry doesn't create a second order. The distinction I'd stress versus a fintech-style question is that here the assertion target is order and inventory state, not a ledger balance.

Model answer

Black Friday is where correctness and performance failures collide, so I'd plan for both at once. Risk order: checkout must stay available (lost checkout = lost revenue), inventory must not oversell under spike concurrency, and promotions must not be exploitable at scale. I'd run load tests that model the real shape — a thundering-herd at sale open, hot products, and concurrent coupon redemption — and within that load assert the inventory race holds (the last-unit test under real parallelism) and the coupon-floor matrix holds. I'd test graceful degradation: queueing, rate limits, and a clear pending state on gateway slowness rather than 500s. Operationally I'd have the rollback plan agreed with infra and payments, real-time dashboards on oversell/error-rate/checkout-conversion, and a kill switch for individual promos. Pre-event I'd freeze risky changes and run the full isolation/checkout/refund regression. The plan is explicitly ranked by revenue impact, because under flash-sale load the rare race becomes common.