How to test an ecommerce store

01Direct answer

02What counts as an ecommerce store

An ecommerce store here means a single-merchant online shop on web and mobile with a catalogue, cart and checkout that takes card payments. It counts when the merchant sells its own stock, shows ship dates at checkout and keeps shopper accounts with saved addresses. A marketplace where many sellers list and get paid out is out of scope, and so is a store whose revenue comes from recurring renewals.

Adjacent product types not covered here

• online marketplace: A marketplace pays out many sellers and carries seller and payout risks a single-merchant store does not have.
• subscription box service: Subscription commerce charges on renewal, so its risk sits in recurring billing and cancellation rather than one-off checkout and refunds.
• grocery delivery app: A grocery delivery app hands orders to couriers in delivery slots, while a single-merchant store ships parcels against a ship date promised at checkout.

03Risk map

04Mandatory tests (10)

1. 1

   Step 1: release smoke tests

   Why:store-rejectionmoney-loss

   Done when: On the release build, a shopper finds a product, adds it to the cart, pays with a test card and receives an order confirmation email.

   Tool class: browser automation. Who usually runs it: QA engineer.

2. 2

   Step 2: integration tests

   Why:money-lossregulatory-penalty

   Done when: Order, payment and fulfilment status match across the storefront, payment provider and warehouse system for paid, shipped, cancelled and refunded orders.

   Tool class: API client. Who usually runs it: developer.

3. 3

   Step 3: end-to-end functional tests

   Why:regulatory-penaltymoney-loss

   Done when: An order for a backordered item that passes its promised ship date triggers a delay email with a working cancel link, and cancelling issues a card refund.

   Tool class: browser automation. Who usually runs it: QA engineer.

4. 4

   Step 4: data integrity and migration testing

   Why:money-loss

   Done when: A daily report shows every cancelled or unshipped order with a card refund, not store credit, unless the shopper chose credit.

   Tool class: data validation. Who usually runs it: QA engineer.

5. 5

   Step 5: payment and money-flow testing

   Why:money-loss

   Done when: A declined card, a 3-D Secure challenge, a partial refund and a full cancellation each leave exactly one matching entry on the test card statement and in the admin order.

   Tool class: API client. Who usually runs it: QA engineer.

6. 6

   Step 6: accessibility testing

   Why:accessibility-liability

   Done when: A screen reader user picks a size and colour, adds the item to the cart and completes checkout with the keyboard alone.

   Tool class: accessibility checker. Who usually runs it: accessibility specialist.

7. 7

   Step 7: compliance checks

   Why:regulatory-penalty

   Done when: A signed checklist shows review moderation treats one-star and five-star reviews by the same rule, and shipping-delay notices follow the mail order rule.

   Tool class: test management. Who usually runs it: product manager.

8. 8

   Step 8: security scanning

   Why:data-breach

   Done when: The checkout page loads only scripts on an approved list, a change to any of them raises an alert, and the scan shows no open high-severity finding.

   Tool class: DAST scanner. Who usually runs it: security specialist.

9. 9

   Step 9: penetration testing

   Why:data-breach

   Done when: A tester signed in as one shopper cannot see another shopper's orders, addresses or saved cards by changing an order or customer id.

   Tool class: proxy. Who usually runs it: security specialist.

10. 10

    Step 10: resilience and failure testing

    Why:dependency-failure

    Done when: With the CDN switched off in staging, the storefront serves from origin or a status page, and no order is charged without being recorded.

    Tool class: chaos tool. Who usually runs it: developer.

05Recommended and optional tests

• regression suiterecommended

  Becomes mandatory when the store releases or updates plugins more than once a month.

• contract testsrecommended

  Becomes mandatory when a second payment or shipping provider is added.

• device and browser compatibilityrecommended

  Becomes mandatory when a native app ships alongside the website.

• performance and load testingrecommended

  Becomes mandatory when a sale or campaign is planned that drives traffic above the store's past peak.

• analytics and event tracking testsrecommended

  Becomes mandatory when ad spend or stock decisions are made from the purchase events.

• unit testsoptional

  May help: discount stacking, tax and shipping rules can be checked in code without a deployed build.

• exploratory testingoptional

  May help: finds odd paths such as editing the cart in two tabs or reusing a single-use code.

• usability testingoptional

  May help: shows where shoppers abandon checkout.

06Not needed and why

• localization testing

  Not needed: one language and one currency. Becomes recommended when the store ships to a second country or currency.

• offline and poor-network testing

  Not needed: shoppers browse and pay online, and payment is confirmed by the server. Becomes recommended when the app lets shoppers build carts offline.

07Order of work

08Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of ecommerce store (web, ios, android). Not recommendations.

09What to send to the person who will test

Send the checklist and the brief below. The printable checklist for ecommerce store has the same 10 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the ecommerce store is accepted when every cancelled or unshipped order ends in a card refund unless the shopper chose store credit, and a backordered item past its ship date triggers a delay email with a working cancel link. The checkout page loads only approved scripts, a screen reader user completes checkout with the keyboard alone, and order status matches across storefront, payment provider and warehouse.

Brief

# Test brief: ecommerce store

Product type: ecommerce store. A single-merchant online shop with catalogue, cart and checkout.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/ecommerce-store/
Printable checklist: https://howtotestaproduct.com/checklists/ecommerce-store/

Run these 10 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: store-rejection, money-loss). Tool class: browser automation. Usually run by: QA engineer.
   Done when: On the release build, a shopper finds a product, adds it to the cart, pays with a test card and receives an order confirmation email.
2. integration tests (risks: money-loss, regulatory-penalty). Tool class: API client. Usually run by: developer.
   Done when: Order, payment and fulfilment status match across the storefront, payment provider and warehouse system for paid, shipped, cancelled and refunded orders.
3. end-to-end functional tests (risks: regulatory-penalty, money-loss). Tool class: browser automation. Usually run by: QA engineer.
   Done when: An order for a backordered item that passes its promised ship date triggers a delay email with a working cancel link, and cancelling issues a card refund.
4. data integrity and migration testing (risks: money-loss). Tool class: data validation. Usually run by: QA engineer.
   Done when: A daily report shows every cancelled or unshipped order with a card refund, not store credit, unless the shopper chose credit.
5. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer.
   Done when: A declined card, a 3-D Secure challenge, a partial refund and a full cancellation each leave exactly one matching entry on the test card statement and in the admin order.
6. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist.
   Done when: A screen reader user picks a size and colour, adds the item to the cart and completes checkout with the keyboard alone.
7. compliance checks (risks: regulatory-penalty). Tool class: test management. Usually run by: product manager.
   Done when: A signed checklist shows review moderation treats one-star and five-star reviews by the same rule, and shipping-delay notices follow the mail order rule.
8. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The checkout page loads only scripts on an approved list, a change to any of them raises an alert, and the scan shows no open high-severity finding.
9. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist.
   Done when: A tester signed in as one shopper cannot see another shopper's orders, addresses or saved cards by changing an order or customer id.
10. resilience and failure testing (risks: dependency-failure). Tool class: chaos tool. Usually run by: developer.
   Done when: With the CDN switched off in staging, the storefront serves from origin or a status page, and no order is charged without being recorded.

Acceptance criteria wording:
A release of the ecommerce store is accepted when every cancelled or unshipped order ends in a card refund unless the shopper chose store credit, and a backordered item past its ship date triggers a delay email with a working cancel link. The checkout page loads only approved scripts, a screen reader user completes checkout with the keyboard alone, and order status matches across storefront, payment provider and warehouse.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

10Questions about testing an ecommerce store

11Evidence

1. ev-0071regulatorprimary

   Fashion Nova Will Pay [amount] for Consumer Refunds To Settle FTC Charges It Violated Rules On Shipping, Refunds, U.S. Federal Trade Commission

   A single-merchant online fashion store was charged under the Mail Order Rule for not sending shipping-delay notices with a cancel option and for issuing gift cards instead of refunds on unshipped items, both order-flow behaviours of an ecommerce store. A subscription box ships ordered merchandise under the same rule, so a late box needs the same delay notice and refund.

   published 2020-04-21 · verified 2026-10-07

2. ev-0017regulatorprimary

   Guidance on Web Accessibility and the ADA, U.S. Department of Justice

   The Department of Justice states that the ADA applies to the websites of businesses open to the public and of state and local governments.

   published undated · verified 2026-10-07

3. ev-0074court-or-fineprimary

   Robles v. Domino's Pizza, LLC, No. 17-55504 (9th Cir. 2019), United States Court of Appeals for the Ninth Circuit

   We agree with the district court that the ADA applies to Domino’s website and app.

   A blind customer could not order through a retailer's website and app with a screen reader, and the court held the ADA applies to them; an online store selling to the public faces the same claim. The holding transfers to any commerce site that sells to the public online, including subscription sign-up and management flows.

   published 2019-01-15 · verified 2026-10-07

4. ev-0072regulatorprimary

   Fashion Nova will Pay [amount] as part of Settlement of FTC Allegations it Blocked Negative Reviews of Products, U.S. Federal Trade Commission

   The FTC acted against an online store whose review tool auto-published four- and five-star reviews and held lower ones for approval, so the product review flow on a store page is a regulated feature.

   published 2022-01-25 · verified 2026-10-07

5. ev-0010standardprimary

   PCI DSS document library, PCI Security Standards Council

   PCI DSS sets security requirements, including vulnerability scanning and penetration testing, for any system that stores, processes or transmits cardholder data.

   published undated · verified 2026-10-07

6. ev-0073court-or-fineprimary

   Penalty Notice: British Airways plc (COM0783542), Information Commissioner's Office

   The ICO penalty describes an attacker modifying a script on a booking site's payment page so card data was copied to an attacker domain while checkout kept working; any store that renders its own card form carries the same exposure.

   published 2020-10-16 · verified 2026-10-07

7. ev-0075post-mortemprimary

   Summary of June 8 outage, Fastly

   Official CDN post-mortem: a valid customer configuration change triggered a software bug and the network returned errors for customer sites. Supports dependency-failure for content management systems that deliver published content through a CDN, and for any storefront whose catalogue, cart and checkout are delivered through a CDN.

   published 2021-06-08 · verified 2026-10-07

8. ev-0001store-guidelineprimary

   App Review Guidelines, Apple

   Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).

   published undated · verified 2026-10-07

12Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.