QA interview guide

How would you test a shopping cart?

A shopping cart looks simple, but it carries pricing, inventory, session, persistence, and checkout risk. Interviewers use this question to see whether you think about product behavior and backend state together.

Practice this scenarioBrowse all questions

Write your own answer and compare it with senior QA coverage.

What interviewers expect

What interviewers expect

Interviewers expect add/remove flows, quantity changes, cart totals, promo codes, empty cart behavior, guest versus logged-in carts, persistence, inventory changes, backend consistency, accessibility, and performance with many items.

Checklist

Checklist

Use these practical prompts to build a complete answer. Strong interview responses usually include functional behavior, negative cases, security, backend/data risks, UX, accessibility, and reliability.

Functional cart behavior

  • Adding one product creates the correct cart line with name, image, price, quantity, and subtotal.
  • Adding multiple products and adding the same product again updates quantity according to requirements.
  • Removing one item, clearing the cart, and reducing quantity to zero behave correctly.
  • Cart count, mini-cart, cart page, checkout button, and continue-shopping links update immediately.
  • Out-of-stock, low-stock, discontinued, and unavailable products cannot be purchased incorrectly.

Pricing, discounts, and data

  • Subtotal, shipping estimate, tax estimate, discount, promo code, and final total are calculated correctly.
  • Currency, rounding, localized formats, and price changes after adding to cart are handled.
  • Cart state persists after refresh, login, logout, session timeout, and browser restart if required.
  • Guest cart merges safely with account cart after login.
  • Inventory availability is rechecked before checkout and stale cart items are explained.

Negative, security, and backend risks

  • Invalid quantity, negative quantity, huge quantity, duplicate submit, and rapid clicks are handled.
  • Users cannot tamper with price, discount, product id, inventory, or cart owner from the client.
  • Backend errors, timeout, network failure, stale cart, and unavailable product states are recoverable.
  • Cart APIs return correct status codes and response schema.
  • Tenant, user, or session isolation prevents seeing another user's cart.

UX, accessibility, and reliability

  • Empty cart, loading state, unavailable item message, and recovery actions are clear.
  • Keyboard navigation, labels, focus states, and screen reader updates work for quantity controls.
  • Mobile layout has usable controls and no horizontal scroll.
  • Large carts remain responsive and do not create slow checkout handoff.
  • Analytics or audit events for cart changes do not leak sensitive user data.

Complete interview coverage checklist

Aim to mention 20-40 concrete checks. This expanded list helps you turn a short answer into a structured senior-style response.

Adding one product creates the correct cart line with name, image, price, quantity, and subtotal.
Adding multiple products and adding the same product again updates quantity according to requirements.
Removing one item, clearing the cart, and reducing quantity to zero behave correctly.
Cart count, mini-cart, cart page, checkout button, and continue-shopping links update immediately.
Out-of-stock, low-stock, discontinued, and unavailable products cannot be purchased incorrectly.
Subtotal, shipping estimate, tax estimate, discount, promo code, and final total are calculated correctly.
Currency, rounding, localized formats, and price changes after adding to cart are handled.
Cart state persists after refresh, login, logout, session timeout, and browser restart if required.
Guest cart merges safely with account cart after login.
Inventory availability is rechecked before checkout and stale cart items are explained.
Invalid quantity, negative quantity, huge quantity, duplicate submit, and rapid clicks are handled.
Users cannot tamper with price, discount, product id, inventory, or cart owner from the client.
Backend errors, timeout, network failure, stale cart, and unavailable product states are recoverable.
Cart APIs return correct status codes and response schema.
Tenant, user, or session isolation prevents seeing another user's cart.
Empty cart, loading state, unavailable item message, and recovery actions are clear.
Keyboard navigation, labels, focus states, and screen reader updates work for quantity controls.
Mobile layout has usable controls and no horizontal scroll.
Large carts remain responsive and do not create slow checkout handoff.
Analytics or audit events for cart changes do not leak sensitive user data.
Structure your answer: Start with add, remove, quantity change, cart count, and checkout handoff.
Structure your answer: Add pricing and data rules: totals, tax, promo codes, inventory, persistence, and guest cart merge.
Structure your answer: Add negative and security cases: invalid quantities, tampering, stale products, backend failures, and isolation.
Structure your answer: Close with UX, accessibility, mobile behavior, performance with many items, and recovery states.
Do not miss: Guest cart merge after login.
Do not miss: Client-side tampering with price, discount, quantity, or product id.
Do not miss: Inventory changes between cart and checkout.
Do not miss: Screen reader updates when cart count or totals change.

Ready to practice?

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario

Answer structure

Strong answer structure

  1. Start with add, remove, quantity change, cart count, and checkout handoff.
  2. Add pricing and data rules: totals, tax, promo codes, inventory, persistence, and guest cart merge.
  3. Add negative and security cases: invalid quantities, tampering, stale products, backend failures, and isolation.
  4. Close with UX, accessibility, mobile behavior, performance with many items, and recovery states.

Common missed areas

Common missed risks

Guest cart merge after login.
Client-side tampering with price, discount, quantity, or product id.
Inventory changes between cart and checkout.
Screen reader updates when cart count or totals change.

Answer template

Use this interview answer template

I would start with add, remove, and quantity updates, then cover totals, tax, discounts, stock changes, guest and logged-in carts, persistence, cart merge, invalid quantities, backend failures, price tampering, checkout handoff, UX, accessibility, and performance.

Use it as a structure, then replace the examples with specific checks for the feature you are discussing.

Common weak answer

“I would test valid and invalid cases.”

This is too generic because it does not show risk thinking. A stronger answer names the happy path, negative cases, security risks, backend/data behavior, UX/accessibility, and reliability concerns that matter for this exact scenario.

Examples

Weak answer vs stronger answer

Weak answer
“I would test adding a product to the cart.”

This checks the most obvious action, but misses quantities, removal, totals, discounts, inventory, persistence, guest cart merge, security tampering, backend errors, and accessibility.

Stronger answer
“I would test adding one product, adding multiple products, duplicate product quantity behavior, removing items, clearing the cart, cart count updates, empty cart state, subtotal, tax, shipping estimate, promo code, final total, price changes, out-of-stock items, guest cart persistence, login cart merge, refresh behavior, invalid and huge quantities, rapid clicks, backend errors, client-side price tampering blocked, cart API status codes, user isolation, keyboard navigation, screen reader updates, mobile layout, and large cart performance.”

FAQ

Frequently asked questions

What should I mention first when answering "How would you test a shopping cart?"

Start with add, remove, quantity change, cart count, and checkout handoff.

Should I include negative and edge cases?

Invalid quantity, negative quantity, huge quantity, duplicate submit, and rapid clicks are handled. Users cannot tamper with price, discount, product id, inventory, or cart owner from the client.

Should I include security, API, or backend risks?

Subtotal, shipping estimate, tax estimate, discount, promo code, and final total are calculated correctly. Currency, rounding, localized formats, and price changes after adding to cart are handled.

What are common missed risks?

Guest cart merge after login. Client-side tampering with price, discount, quantity, or product id. Inventory changes between cart and checkout. Screen reader updates when cart count or totals change.

How can I practice this answer?

Use the interactive how would you test a shopping cart? challenge to write your own answer, get checklist-based feedback, and compare your coverage with stronger QA thinking.

Practice

Practice this scenario interactively

Write your own answer and compare it with senior QA coverage.

Practice this scenario