Skip to content

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.

QA Workflow Assistant12 min read
  • 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:

AreaExamples
Line itemsAdd, remove, update qty
Catalog rulesMin/max qty, packs, subscriptions
PricingDiscounts, taxes display, currency
InventoryOversell prevention, reservations
IdentityGuest cart, login merge
PersistenceRefresh, multi-tab, expiry
HandoffCheckout 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

CaseExpect
Qty below minimum (min 3)Validation; cart not silently accepting 1
Qty above maximumCap or error per rules
Decimal qty on integer SKURejected
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."

CaseExpect
Bundle added as a single lineComponent items not individually editable unless product allows unbundling
Removing the bundleAll component items removed together, not orphaned partial lines
Digital item mixed with physical itemShipping fields apply only to the physical line; totals reflect the split correctly
Subscription item mixed with one-time itemCheckout clearly separates recurring total from one-time total; confirmation states both
Bundle discount vs individual item discountDocumented 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.

ScenarioExpect
Add item on mobile app, open web cartItem appears once merge/sync completes; no duplicate line
Modify quantity on web while app is offlineApp reconciles on reconnect without silently reverting the web change
Log out on one deviceOther logged-in device's cart is unaffected unless product defines shared-session behavior
Two devices submit checkout near-simultaneouslyOnly 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.

ScenarioExpect
Currency switched with items already in cartPrices 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 rulesTax line updates or disappears per the new region's rules; no leftover tax from the previous region
Region switch removes an item's availabilityItem flagged unavailable with a clear reason, not silently dropped without explanation
Locale switch changes number formattingThousands/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

  1. Add + increment + remove
  2. Min/max qty
  3. Valid discount + expired discount
  4. Low stock enforcement
  5. Guest → login merge
  6. 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:

MechanismExample assertion
Manual couponCode entry applies once; removal restores totals
Automatic promoQualifying SKU discount appears without code
Exclusion rulesCoupon cannot combine with clearance pricing
Gift-with-purchaseFree 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.