Test Cases for an E-commerce Website

If you are building test cases for an e-commerce website, you are protecting revenue, inventory integrity, and customer trust at the same time. An ecommerce system is not one page. It is a chain: discover product, evaluate details, add to cart, apply offers, calculate tax and shipping, pay, fulfill, and support returns. A defect anywhere in that chain can mean abandoned carts, overselling, undercharging, or broken order history.

This guide gives you a practical, risk-based suite design for ecommerce testing. You will get module-by-module scenarios, sample cases, prioritization for release and sale events, payment and inventory checks, and common mistakes teams make when they only test the happy path with a perfect card and one in-stock SKU.

Test Cases for an E-commerce Website: Scope Map

Break the product into modules so cases stay maintainable.

1. Home and navigation.
2. Search and category browse.
3. Product detail page (PDP).
4. Cart.
5. Checkout and address.
6. Pricing, tax, shipping, coupons.
7. Payments.
8. Order confirmation and notifications.
9. Customer account and order history.
10. Inventory and catalog admin effects.
11. Returns, cancellations, refunds.
12. Cross-cutting: auth, mobile, accessibility, performance smoke, security.

You will not execute every case every day. You will always know where each case lives.

Risk-Based Priority Model

Risk area	Why it matters	Default priority
Checkout and payment success	Direct revenue	P0
Cart price integrity	Over/under charge	P0
Inventory decrement	Oversell/undersell	P0
Login and account orders	Trust and privacy	P0
Search finds key products	Conversion	P1
Coupons and promotions	Margin leakage	P1
Shipping/tax calculations	Legal and support cost	P1
Returns/refunds	Cost and compliance	P1
Wishlist/recommendations	Conversion support	P2
Cosmetic merchandising	Brand, lower direct risk	P2/P3

When time is short, defend P0 first. For writing quality and structure, use how to write test cases as your baseline craft guide.

For commerce flows that accept receipts, prescriptions, returns evidence, or bulk product files, add focused test cases for file upload to the relevant module.

Module 1: Navigation, Home, and Catalog Browse

ID	Title	Expected
TC-ECOM-001	Home page loads key entry points	Search, cart, login, featured categories visible
TC-ECOM-002	Category navigation opens correct listing	Products match category
TC-ECOM-003	Breadcrumbs reflect hierarchy	Correct path and links work
TC-ECOM-004	Sort by price ascending	Order is correct for displayed currency
TC-ECOM-005	Sort by newest	Order matches catalog rules
TC-ECOM-006	Filter by brand/size/color	Only matching products shown
TC-ECOM-007	Clear filters	Full listing restored
TC-ECOM-008	Pagination or infinite scroll	No duplicates, no missing page items
TC-ECOM-009	Empty category state	Helpful empty message
TC-ECOM-010	Sold out badge appears when stock is zero	Badge and constrained CTA match rules

Module 2: Search

Search deserves its own deep suite. Summarize core ecommerce search cases here and link out for depth to test cases for search functionality.

ID	Title	Expected
TC-ECOM-020	Exact product name search	Target product in results
TC-ECOM-021	Partial keyword search	Relevant matches
TC-ECOM-022	No results query	Empty state and suggestions if any
TC-ECOM-023	Search result price matches PDP	Same price before discounts rules
TC-ECOM-024	Out of stock products handling	Shown/hidden per config

Module 3: Product Detail Page (PDP)

PDP defects cause wrong purchases.

ID	Title	Expected
TC-ECOM-030	Product title, images, price render	Content correct for SKU
TC-ECOM-031	Variant selection updates price/SKU	Correct SKU selected
TC-ECOM-032	Variant out of stock	Cannot add that variant
TC-ECOM-033	Quantity default and change	Bounds respected
TC-ECOM-034	Add to cart from PDP	Cart count and line item correct
TC-ECOM-035	Add to wishlist if present	Item saved to wishlist
TC-ECOM-036	Product description formatting	No broken layout, safe HTML
TC-ECOM-037	Reviews list pagination	Stable ordering
TC-ECOM-038	Low stock messaging	Shows when below threshold
TC-ECOM-039	Image gallery navigation	All images reachable

Detailed example:

Test Case ID: TC-ECOM-031
Title: Verify selecting size and color updates selectable SKU and price
Preconditions: Product has size S/M and color Black/Blue with different stock/price rules
Steps:
  1. Open PDP for configurable product.
  2. Select Black and M.
  3. Observe price, stock state, and SKU or data attributes if visible.
  4. Change to Blue and S.
Expected:
  - Displayed price matches the selected variant.
  - Add to cart targets the selected variant only.
  - Stock state matches that variant, not the parent product aggregate incorrectly.

Module 4: Cart Test Cases

Cart is the bridge between intent and checkout.

ID	Title	Expected
TC-ECOM-040	Add single item	Line created with correct unit price
TC-ECOM-041	Add same item again	Quantity increments per rules
TC-ECOM-042	Add different variants	Separate lines if variants differ
TC-ECOM-043	Update quantity upward	Totals recalculate
TC-ECOM-044	Update quantity downward	Totals recalculate
TC-ECOM-045	Set quantity to zero or remove	Line removed
TC-ECOM-046	Quantity above stock	Blocked with message
TC-ECOM-047	Quantity below minimum	Blocked if min pack size exists
TC-ECOM-048	Cart persistence for guest	Survives browser refresh
TC-ECOM-049	Cart merge after login	Guest and user carts merge per policy
TC-ECOM-050	Remove all items	Empty cart state
TC-ECOM-051	Price change while item in cart	Policy: update price or lock, user informed
TC-ECOM-052	Item becomes out of stock in cart	Cannot checkout that item

Calculation checks

Always verify:

• Line total = unit price x quantity (after line discounts if any).
• Subtotal sums lines correctly.
• Taxes and shipping appear only where designed (cart vs checkout).
• Currency symbols and decimal precision are correct.

ID	Title	Expected
TC-ECOM-053	Subtotal with two lines	Exact arithmetic match
TC-ECOM-054	Discounted line item	Discount applied once, not duplicated on refresh

Module 5: Coupons, Promotions, and Loyalty

Promotions are notorious for margin bugs.

ID	Title	Expected
TC-ECOM-060	Valid percentage coupon	Correct discount amount
TC-ECOM-061	Valid fixed amount coupon	Correct discount, not below zero incorrectly
TC-ECOM-062	Expired coupon	Rejected
TC-ECOM-063	Not yet active coupon	Rejected
TC-ECOM-064	Coupon below minimum cart value	Rejected
TC-ECOM-065	Coupon restricted to category	Works only for eligible items
TC-ECOM-066	Single-use coupon second attempt	Rejected
TC-ECOM-067	Stacking two coupons	Allowed only if policy permits
TC-ECOM-068	Remove coupon	Totals restore
TC-ECOM-069	Coupon after cart change	Revalidated, not silently wrong
TC-ECOM-070	Free shipping promo threshold	Shipping becomes zero when met

Regression classic:

Title: Coupon not duplicated after checkout page refresh
Steps:
  1. Apply SAVE10.
  2. Confirm discount once.
  3. Refresh checkout.
Expected:
  - Discount remains applied once.
  - Payable total is unchanged and correct.

Module 6: Checkout, Address, Shipping, Tax

ID	Title	Expected
TC-ECOM-080	Guest checkout available if enabled	Can proceed without full account
TC-ECOM-081	Logged-in checkout uses saved address	Address prefilled correctly
TC-ECOM-082	Required address fields validation	Missing fields block progress
TC-ECOM-083	Invalid postal code format	Rejected
TC-ECOM-084	Shipping methods for destination	Only valid methods shown
TC-ECOM-085	Shipping cost updates on method change	Totals update
TC-ECOM-086	Tax calculation for region A	Tax matches rule engine
TC-ECOM-087	Tax-exempt scenario if supported	Tax zero with valid exemption
TC-ECOM-088	Order review shows accurate summary	Items, discounts, shipping, tax, total
TC-ECOM-089	Edit cart from checkout	Returns and recalculates safely
TC-ECOM-090	Double click place order	Only one order created

Use realistic addresses per market. Fake happy-path addresses often miss validation rules.

Module 7: Payment Test Cases

Never treat payment as a black box you ignore. Use sandbox modes.

ID	Title	Expected
TC-ECOM-100	Successful card payment	Order paid, confirmation shown
TC-ECOM-101	Declined card	No paid order, recoverable error
TC-ECOM-102	Expired card	Rejected with clear reason class
TC-ECOM-103	Incorrect CVV	Rejected
TC-ECOM-104	Insufficient funds	Rejected, cart preserved if policy says so
TC-ECOM-105	3DS challenge success	Payment completes after challenge
TC-ECOM-106	3DS challenge failure	No capture, order not marked paid
TC-ECOM-107	User cancels on payment provider	Returns safely, no charge
TC-ECOM-108	Payment timeout	Order state is consistent, no silent charge
TC-ECOM-109	Alternative method (wallet/COD/UPI/etc.)	Method-specific success path works
TC-ECOM-110	Paid order inventory committed	Stock reduced according to policy
TC-ECOM-111	Failed payment inventory not stolen	Stock not permanently decremented incorrectly

Order vs payment consistency matrix

Payment result	Expected order status	Inventory	User messaging
Success	Paid / confirmed	Decremented	Confirmation
Decline	Failed / pending payment	Not taken or released	Retry guidance
Cancel at provider	Cancelled/pending	Released	Can retry
Timeout unknown	Pending reconciliation state	Locked temporarily or per design	"Processing" guidance

Inconsistent states here create serious finance and support problems.

Module 8: Order Confirmation, Notifications, Account

ID	Title	Expected
TC-ECOM-120	Confirmation page order number	Unique ID shown
TC-ECOM-121	Confirmation email content	Items, total, address correct
TC-ECOM-122	Order visible in account history	Same totals and status
TC-ECOM-123	Unauthorized user cannot open order URL	Access denied
TC-ECOM-124	Invoice download if available	Correct amounts
TC-ECOM-125	Cancel order before fulfillment	Status updated, payment void/refund rules apply
TC-ECOM-126	Order status progression	Pending -> paid -> shipped -> delivered as designed

Security note: insecure direct object references on /orders/{id} are common. Include authorization cases.

Module 9: Inventory and Catalog Consistency

ID	Title	Expected
TC-ECOM-130	Purchase reduces stock	Stock decreases by purchased qty
TC-ECOM-131	Two users compete for last item	Only one successful paid purchase
TC-ECOM-132	Admin sets stock to zero	PDP/cart prevent purchase
TC-ECOM-133	Backorder allowed if configured	Messaging and promise dates correct
TC-ECOM-134	Bundle product stock	Bundle rules enforce component availability

Race conditions around last-item purchases are high value and often missed in single-threaded manual tests. Include at least a planned concurrent scenario for big sales.

Module 10: Returns, Refunds, Exchanges

ID	Title	Expected
TC-ECOM-140	Eligible order starts return	Return request created
TC-ECOM-141	Outside return window	Request blocked
TC-ECOM-142	Partial return quantity	Refund amount proportional per policy
TC-ECOM-143	Restocking fee if any	Fee calculated correctly
TC-ECOM-144	Refund method	Original payment method or store credit per rules
TC-ECOM-145	Exchange flow	Replacement order or adjustment correct

Auth and Account Touchpoints

Ecommerce depends on auth for saved addresses, order history, and wishlist. Include a thin slice of login/register coverage and link deeper suites:

• test cases for login page
• registration flows if account-required checkout exists

ID	Title	Expected
TC-ECOM-150	Login from checkout	Returns user to checkout, cart intact
TC-ECOM-151	Logout clears private order data from UI	No easy access to previous account orders on shared device

Mobile, Accessibility, and Cross-Browser Smoke

Revenue often happens on mobile.

ID	Title	Expected
TC-ECOM-160	Mobile add to cart and checkout smoke	Can complete purchase on target mobile browser
TC-ECOM-161	Sticky cart/checkout CTAs usable	Not obscured by banners
TC-ECOM-162	Keyboard navigate critical path	Search -> PDP -> cart -> checkout fields usable
TC-ECOM-163	Form errors announced	Address/payment errors understandable

You do not need full WCAG audit in every ecommerce regression, but smoke accessibility on money paths is justified.

End-to-End Journey Cases

Keep a small number of journey cases in addition to modular tests.

Journey A: Guest buys in-stock simple product

1. Search product.
2. Open PDP.
3. Add to cart.
4. Checkout as guest.
5. Pay successfully.
6. Receive confirmation.

Journey B: Logged-in user buys variant with coupon

1. Login.
2. Select variant.
3. Apply coupon.
4. Pay with 3DS success.
5. Verify order history.

Journey C: Payment decline recovery

1. Add item.
2. Pay with decline fixture.
3. Retry with success fixture.
4. Confirm single successful order and correct stock.

Journeys prove integration. Modular cases diagnose failures faster.

Sample High-Value Mini Suite (Release Smoke)

1. Search key SKU.
2. PDP variant select and add.
3. Cart quantity update totals.
4. Valid coupon apply/remove.
5. Checkout address validation.
6. Successful payment.
7. Confirmation + order history.
8. Failed payment does not mark paid.
9. Out of stock cannot checkout.
10. User A cannot open user B order.

If these ten pass, the store is not "fully tested," but it is often testable and revenue-safe enough for deeper runs.

Test Data and Environment Needs

Ecommerce testing quality depends on data.

Data need	Example
In-stock simple SKU	Always available product
Low-stock SKU	Stock = 1
Configurable variants	Size/color matrix
Coupon set	valid, expired, restricted, single-use
Users	guest path, buyer, buyer with prior orders
Addresses	domestic valid, invalid postal, international if supported
Payment fixtures	success, decline, 3DS

Reset coupons and stock regularly. Shared sandbox pollution creates false failures.

Common Mistakes in Ecommerce Test Cases

Mistake 1: Only happy path with one product

Misses variants, coupons, declines, and stock races.

Mistake 2: Not validating money math

"Looks roughly right" is not an expected result. Compute exact totals.

Mistake 3: Ignoring order/payment state consistency

UI success with unpaid order, or charge without order, are critical defects.

Mistake 4: No authorization tests on orders

IDOR issues leak personal purchase data.

Mistake 5: Cart tested without login merge rules

Guest-to-user transitions break often.

Mistake 6: Treating coupons as cosmetic

Promotions are financial logic.

Mistake 7: No mobile checkout execution

Desktop-only confidence is false confidence for many stores.

Mistake 8: Unmaintainable mega cases only

A 90-step case that buys everything helps demos, not debugging. Balance journeys and atomic cases.

Using Boundaries in Ecommerce Inputs

Quantity, coupon codes, address lengths, and postal fields all benefit from boundary thinking. For technique detail, see boundary value analysis and equivalence partitioning.

Examples:

• Quantity min, min-1, max stock, max stock+1.
• Coupon max uses.
• Address line max length.
• Phone field bounds.

Automation Candidates vs Manual Focus

Automate first:

• Critical journey smoke.
• Cart calculations for fixed fixtures.
• Coupon application arithmetic with stable promos.
• Authz checks on order endpoints if API accessible.
• Out of stock CTA state with controlled stock APIs.

Keep manual/exploratory:

• Visual merchandising.
• Complex promotion combinations newly launched.
• Usability of mobile payment sheets.
• Content correctness of new campaign pages.

Sale Event and Flash Sale Checklist

Before high traffic campaigns:

1. P0 smoke on production-like env.
2. Coupon codes for the event.
3. Inventory for featured SKUs.
4. Payment provider status and 3DS paths.
5. Mobile checkout.
6. Order confirmation email deliverability sample.
7. Feature flags and fallback plan.
8. Monitoring dashboards for checkout errors.
9. Load awareness of search and checkout APIs.
10. Rollback owner identified.

Testing is part of sale readiness, not a postmortem tool.

Practice Plan

Use a demo store or staging catalog and build:

1. A module map.
2. 30 scenarios across cart, checkout, payment.
3. 15 fully detailed cases with exact expected totals.
4. A 10-case smoke pack.
5. A list of open questions on tax and coupon stacking.

To sharpen speed and prioritization under pressure, practice scenario design in QABattle battles and then convert notes into formal ecommerce cases.

Review Checklist

• Money paths covered end to end.
• Cart math verified.
• Payment success and failure covered.
• Inventory effects covered.
• Coupon rules covered for active promos.
• Order history and authz covered.
• Mobile smoke covered.
• Guest and logged-in paths considered.
• Returns policy covered if live.
• Test data reset strategy exists.
• P0 suite can run quickly before release.

Conclusion

High quality test cases for an e-commerce website delivery start from revenue risk, not from random page tours. Cover discovery, PDP accuracy, cart integrity, checkout calculations, payment truth, inventory, and account order privacy. Use modular cases for diagnosis and a few journeys for integration confidence. Exact expected totals, state consistency, and out-of-stock behavior matter as much as button clicks.

If your suite can answer, "Can a real customer reliably pay the right amount for an available product and see the right order afterward?" you are focused on the right ecommerce outcome. Expand from that core with promotions, returns, and edge markets as your business model demands.