Q6 of 22 · Scenarios
How would you test a shopping cart?
ScenariosMidscenarioshopping-cartfunctionalsecuritye-commerce
Short answer
Short answer: Clarify persistence model and inventory reservation behavior, then cover item operations, price and quantity math, coupon codes, security (price manipulation, IDOR), and stale-price handling.
Detail
Clarify first
- Is the cart persistent (tied to a logged-in account) or session-only (guest)?
- Is there a maximum number of items or quantity per item?
- Does adding an item to the cart reserve inventory, or does reservation happen at checkout?
- Are cart contents synced across devices for logged-in users?
Functional
- Adding an item increases quantity if the item already exists in the cart, or creates a new line
- Updating quantity recalculates the line total and cart total correctly
- Removing an item updates the total and removes the line from the cart view
- Cart persists across browser sessions for logged-in users
- VAT, taxes, and shipping are calculated correctly and updated when the cart changes
Negative / error handling
- Adding an out-of-stock item → clear message; item not added or added with warning
- Adding more than maximum quantity → quantity capped or error message shown
- Applying an invalid, expired, or already-used coupon code → specific error message
- Item removed from the catalogue while in the cart → handled gracefully at checkout (not a silent data error)
Edge & boundary
- Adding the same item multiple times rapidly (race condition — should aggregate correctly)
- Cart total at exactly a coupon threshold (e.g., 10% off orders over £50 — test at £49.99 and £50.00)
- Cart with a large number of different items (50+ lines)
- Price changes server-side while item is in the cart — stale price detected at checkout, not silently accepted
Security
- Price manipulation via direct API call: modify the cart item price in the request body — server must validate price from its own catalogue, never from client input
- Cart contents are not accessible across user accounts (IDOR check: can user A view or modify user B's cart by changing the cart ID?)
Performance
- Cart total recalculation latency with many items; page load time for a large cart
Close: automate quantity math, coupon boundary values, and IDOR check via API. Keep manual/exploratory for stale-price UX scenarios and multi-device sync edge cases.
// WHAT INTERVIEWERS LOOK FOR
Server-side price validation (client can't set price = 0), IDOR check on cart ownership, and the stale-price detection at checkout. These are the non-obvious defects that slip through basic cart testing.
// COMMON PITFALL
Testing only add/remove/update operations and missing the security concerns. Price manipulation via API and IDOR are common cart vulnerabilities that functional UI testing won't catch.