Blog
Shopping Cart Test Cases with Real Examples
Shopping cart test cases with real examples for quantity rules, stock, discounts, guest carts, and checkout handoff for ecommerce QA teams.
- ecommerce
- shopping-cart
- test-cases
- manual-testing
Carts look simple until you meet concurrent stock, stacking discounts, guest-to-user merges, and “quantity zero” surprises. Solid shopping cart test cases protect revenue paths without turning every UI tweak into a full checkout marathon.
Use this as a modular suite. Keep payment settlement assertions in the payment testing checklist. For case structure discipline, lean on how to write QA test cases.
Cart domain map
Break the problem before writing dozens of near-duplicates:
| Area | Examples |
|---|---|
| Line items | Add, remove, update qty |
| Catalog rules | Min/max qty, packs, subscriptions |
| Pricing | Discounts, taxes display, currency |
| Inventory | Oversell prevention, reservations |
| Identity | Guest cart, login merge |
| Persistence | Refresh, multi-tab, expiry |
| Handoff | Checkout entry with locked totals |
Suite preconditions
- Catalog fixtures: in-stock SKU, low-stock SKU (qty 2), out-of-stock SKU, digital good if applicable
- Discount codes: valid percentage, valid fixed, expired, single-use consumed
- Guest and registered personas
- Known tax region fixture if cart shows tax estimates
Add / update / remove examples
Add in-stock item from PDP
Title: Guest adds in-stock SKU and sees correct line price and quantity 1
Expect: Cart count badge updates; line subtotal = unit price; stock still available.
Add same SKU again increments quantity
Expect: Single line with qty 2 (unless product is non-mergeable); totals recalculate once.
Update quantity via cart input
Expect: Qty 5 → totals update; illegal qty rejected with message.
Remove line item
Expect: Line gone; totals recompute; empty cart state if last item.
Add out-of-stock SKU blocked
Type: Negative
Expect: Clear unavailable state; cannot proceed toward checkout with that line.
Quantity and catalog rule cases
| Case | Expect |
|---|---|
| Qty below minimum (min 3) | Validation; cart not silently accepting 1 |
| Qty above maximum | Cap or error per rules |
| Decimal qty on integer SKU | Rejected |
| Pack size increments (sell by 5) | Only valid multiples accepted |
These are fertile edge case testing opportunities—especially when mobile steppers and desktop inputs disagree.
Pricing and discount cases
Percentage code applies once
Data: SAVE10 = 10% off eligible subtotal
Expect: Discount line visible; tax/shipping rules match finance notes; removing code restores price.
Cannot stack excluded codes
Expect: Second code rejected or replaces per policy—assert the documented rule.
Expired code rejected
Type: Negative
Expect: No partial discount; stable error.
Category exclusions honored
Expect: Code for “apparel only” does not discount electronics lines.
Currency consistency
Expect: Symbol and amount formatting match store currency; no mixed currency math.
Inventory and concurrency
Low stock cannot oversell in UI
Start with qty available = 2. Attempt qty 3 → blocked.
Concurrent carts racing last item
Two sessions attempt the last unit. Expect: Only one checkout reservation succeeds; the other sees stock error before paid fulfillment. Timing differs by architecture (soft reserve vs commit-at-pay)—document yours in suite notes.
Price change after item sits in cart
If product price updates, Expect: cart refresh policy (keep old price vs update vs warn) matches product decision. Surprise silent changes create chargebacks.
Guest, login, and merge behavior
Guest cart persists in session/browser
Refresh → items remain per policy.
Login merges guest cart into user cart
Expect: Documented merge strategy (union, prefer user, prefer guest). No duplicate lines unless intentional. Totals correct after merge.
Logout leaves appropriate cart state
Private prices/lists should not leak on shared devices if that is a requirement.
Persistence and multi-tab
Two tabs update quantity
Last write wins or conflict message—never corrupt totals to NaN or negative.
Cart expiry for abandoned guests
After TTL, cart empty or recoverable per design; messaging not alarming.
Bundles, kits, and mixed cart types
Bundled products and mixed line types (physical + digital + subscription) break assumptions that "one line = one price."
| Case | Expect |
|---|---|
| Bundle added as a single line | Component items not individually editable unless product allows unbundling |
| Removing the bundle | All component items removed together, not orphaned partial lines |
| Digital item mixed with physical item | Shipping fields apply only to the physical line; totals reflect the split correctly |
| Subscription item mixed with one-time item | Checkout clearly separates recurring total from one-time total; confirmation states both |
| Bundle discount vs individual item discount | Documented stacking rule enforced—assert the actual rule, not an assumption |
Bundle quantity edit propagates correctly
Title: Increasing bundle quantity updates all component quantities proportionally
Expect: Qty 2 of a 3-item bundle shows 6 total components in any breakdown view; price recalculates from the bundle price, not the sum of individually-priced components unless that is the documented model.
Gift options and personalization
Gift-related fields are easy to under-test because they feel cosmetic, but they carry into fulfillment and customer communication.
- Gift wrap option adds the correct fee and appears on the packing slip
- Gift message saves and prints correctly, including special characters and emoji if allowed
- Gift receipt (no prices shown) generates a separate document from the standard receipt
- Selecting a gift option for only one line item does not apply it to the whole order
- Removing the gift-optioned item also removes its associated gift fee
Cross-device and cross-session cart sync
Products with both web and native apps need explicit sync cases—assumptions from single-platform carts do not transfer.
| Scenario | Expect |
|---|---|
| Add item on mobile app, open web cart | Item appears once merge/sync completes; no duplicate line |
| Modify quantity on web while app is offline | App reconciles on reconnect without silently reverting the web change |
| Log out on one device | Other logged-in device's cart is unaffected unless product defines shared-session behavior |
| Two devices submit checkout near-simultaneously | Only one order created; second device sees a clear "already completed" state, not a duplicate charge |
Shipping method selection affecting cart totals
Shipping method change updates total before payment
Expect: Selecting expedited shipping updates the displayed total immediately; tax recalculates if shipping is taxable in the fixture region; the previously displayed total does not carry into checkout as stale.
Free shipping threshold crossed and uncrossed
Data: Free shipping at $50 subtotal
Expect: Adding an item that crosses $50 removes the shipping charge live in the cart; removing an item that drops below $50 restores it, with a visible explanation rather than a silent total change.
Address change invalidates an incompatible shipping method
Expect: Switching to an address the selected carrier does not serve resets or clearly flags the shipping method, rather than proceeding to checkout with an invalid combination.
B2B cart considerations
Business buyers introduce fields consumer carts rarely need.
- PO number field accepts and persists through checkout when required by account settings
- Quote request converts to a cart with the quoted (not list) pricing
- Tax-exempt account does not show tax on the cart total when a valid exemption is on file
- Net-terms payment option only appears for accounts approved for it
- Bulk quantity discount tiers apply at the correct threshold and are visible before checkout, not as a surprise at payment
Checkout handoff cases
Cart’s job ends when checkout starts with a coherent snapshot:
- Checkout shows same lines and quantities
- Discounts still applied
- Out-of-stock revalidation runs before payment
- User can return to cart and edit unless order is locked post-payment
Do not retest full PSP declines here—link out to payment suite.
Currency and locale switching mid-session
Global storefronts let shoppers change region or currency after items are already in the cart. This is a frequent source of silently wrong totals.
| Scenario | Expect |
|---|---|
| Currency switched with items already in cart | Prices recalculate from the source price list in the new currency, not a client-side exchange-rate multiply on the old price |
| Region switch changes tax rules | Tax line updates or disappears per the new region's rules; no leftover tax from the previous region |
| Region switch removes an item's availability | Item flagged unavailable with a clear reason, not silently dropped without explanation |
| Locale switch changes number formatting | Thousands/decimal separators match the locale without altering the underlying numeric value |
Currency switch does not corrupt an in-progress discount
Expect: A percentage-based code recalculates correctly in the new currency; a fixed-amount code either converts per a documented rate or is flagged as region-specific—assert whichever your product ships, since silently applying a fixed USD amount as the number of EUR is a real bug class.
Cart abandonment recovery testing
Abandonment emails and recovery links touch cart state well after the original session, which creates its own edge cases.
- Recovery link restores the cart's contents and pricing as of the abandonment snapshot, not current live pricing, unless the product explicitly re-prices
- Recovery link for an item now out of stock shows a clear substitution or removal message
- Recovery link used twice does not create two separate carts for the same session
- Expired recovery link fails gracefully with a path back to browsing
- Recovery email respects unsubscribe/marketing consent status at send time, not signup time
Accessibility and UX smoke (cart-specific)
Not full a11y audits, but cart traps show up often:
- Quantity steppers keyboard operable
- Remove buttons have accessible names
- Errors announced or visible near fields
Sample mini-suite for a cart sprint
- Add + increment + remove
- Min/max qty
- Valid discount + expired discount
- Low stock enforcement
- Guest → login merge
- Checkout snapshot match
Promote to automation when selectors stabilize. Keep concurrency races manual or specialized jobs.
Traceability tips for ecommerce stories
Rewrite “as a shopper I want a cart” into measurable cases:
- Merge rule named in acceptance criteria
- Discount stacking matrix attached
- Inventory source of truth identified (OMS vs storefront cache)
Story intake patterns: From Jira story to structured QA workflow. Coverage depth: Basic / Standard / Deep. Plans: Pricing. Setup: Docs.
Coupons versus line-item promotions
Teams often mix “cart coupon codes” with “automatic catalog promotions.” Split cases:
| Mechanism | Example assertion |
|---|---|
| Manual coupon | Code entry applies once; removal restores totals |
| Automatic promo | Qualifying SKU discount appears without code |
| Exclusion rules | Coupon cannot combine with clearance pricing |
| Gift-with-purchase | Free item appears at threshold and disappears below it |
When promotions change mid-session (admin publishes a sale), decide whether open carts reprice immediately and test that decision explicitly—silent repricing is a common dispute driver.
Empty-cart and resume UX
- Empty cart copy offers a path back to catalog
- Removing the last item does not leave a broken checkout CTA
- Returning shoppers with an expired cart see a calm recovery state, not a stack trace
- Saved-for-later (if present) does not double-count inventory reservations
These are small cases that prevent noisy support tickets after marketing campaigns spike traffic.
FAQ
Should every SKU type have its own cart case?
Parameterize when rules match. Split when digital goods, subscriptions, or preorders change cart behavior.
How do we test carts with personalized pricing?
Use accounts with known price lists; assert server-calculated line prices, not only UI strings.
Are visual cart tests worth it?
Snapshot the empty and dense cart states if layout regressions break checkout CTAs; keep business rules in functional cases.
What about marketplace multi-vendor carts?
Add vendor shipping split and partial availability cases—do not pretend single-vendor suites cover them.
How do we test bundles without maintaining a separate suite per bundle?
Parameterize by bundle structure (fixed-component vs configurable) rather than by individual product. Most bundle bugs come from the mechanism, not the specific SKUs inside it.
Do gift options need their own automated coverage?
Automate the fee calculation and packing-slip data path; leave message rendering and print-layout checks manual or snapshot-based, since they change more often than the underlying logic.
Final checklist
- Add/update/remove covered for mergeable and non-mergeable SKUs
- Min/max/step quantity rules asserted
- Discount success, expiry, and exclusion covered
- Out-of-stock and low-stock behaviors verified
- Guest persistence and login merge documented and tested
- Multi-tab and expiry behaviors known
- Checkout handoff compares snapshots
- Price-change policy explicit
- Payment details deferred to payment suite
- Fixtures include low-stock and discount codes
- Bundle add/remove/quantity propagation verified
- Gift options tested end-to-end into packing slip and receipt
- Cross-device cart sync checked for duplicate or lost lines
- Shipping method changes verified against totals and address compatibility
- B2B-specific fields (PO number, tax exemption, net terms) tested if offered
CTA — expand cart acceptance criteria into executable rows
When product writes “support promo stacking,” turn the matrix into structured cart cases with QA Workflow Assistant, then keep inventory race notes in suite headers where automation should not pretend determinism. Configure workspaces via Docs.
Related articles
How to Write QA Test Cases: A Practical Guide for QA Engineers
Learn how to write clear, maintainable QA test cases with practical examples, templates, and best practices for manual and modern software testing teams.
August 1, 2026 · 13 min read
Negative Test Cases: Examples Every QA Engineer Should Use
Learn how to design negative test cases with practical examples for validation, authorization, state conflicts, and API failures that catch real defects.
August 8, 2026 · 12 min read
Password Reset Test Cases (Complete Checklist)
Password reset test cases and a complete checklist for request, email token, expiry, reuse, and post-reset session handling in modern apps.
August 7, 2026 · 13 min read