Ecommerce Testing Checklist Before Launch: 60 Checks.

An ecommerce testing checklist is for store owners who are about to launch or relaunch a site and want to be sure a customer can find a product, add it to the cart and pay. Below are 60 checks grouped by the stages of the buyer's journey. You can work through them yourself in an evening or hand them to a tester. We use exactly this skeleton when we prepare an ecommerce QA audit, although in practice the list is much longer: around 150 checks.

The main idea is simple. Not everything in a store matters equally. A bug in the footer costs you some nerves; a bug in the cart costs you money. So we test in order of money: payment and checkout first, then the cart and catalog, then everything else.

How to use the checklist

Prepare three things before you start.

• A test environment (staging) that is as close to production as possible: the same PHP and database versions, the same integrations, but in sandbox mode. There is no need to test payments with a real card on production.
• A set of test data: several products in different states (in stock, running low, out of stock, with variants, discounted), 2–3 accounts, promo codes and the payment provider's test cards.
• Devices: at least one iPhone with Safari, one Android phone with Chrome, and a desktop with Chrome and Firefox. DevTools emulation is useful, but real iOS Safari breaks in different ways.

Mark every item as passed, failed or not applicable. For every failure, record the steps to reproduce, the expected and actual result, the device, and a screenshot or video. We walk through a good bug description in the article How We Test: A Bug Report and Test Case Example.

1. Catalog and search (10 checks)

The catalog creates the first impression and brings in search traffic, so here we check both functionality and data.

1. All categories open, with no empty pages and no 500 errors in the list.
2. The product count in the category counter matches the number of products on the page.
3. Filters work alone and in combination; the URL changes when they are applied, and the link brings you back to the same result.
4. Resetting filters returns the full list, not "nothing found".
5. Price sorting really sorts numbers, not strings: 900 does not come after 10,000.
6. Pagination: the last page and an out-of-range page (?page=999) give a clear response, not an error.
7. Search finds a product by name, by SKU and with a one-letter typo; Cyrillic and Latin work the same.
8. An empty search result shows a hint and popular categories.
9. Product page: photos, price, description, variants and availability display correctly; products without photos get a placeholder.
10. An out-of-stock product cannot be bought but can still be found, and there is a "notify me" button or similar products.

Check prices separately. The price in the listing, on the product page, in the cart and at checkout must be identical to the cent, taking discounts and rounding into account.

2. Cart (8 checks)

The cart looks simple, but it holds the most logic: prices, stock, coupons.

11. Adding a product from the product page, from a listing and from "quick view" works the same way.
12. Changing the quantity recalculates the total instantly; a quantity of 0 or a negative quantity does not break the cart.
13. You cannot add more than is in stock, and the message about it is clear.
14. Removing a product and clicking "undo" leaves no "ghosts" in the cart icon counter.
15. The cart survives a page refresh, closing the tab and logging in (the guest cart merges with the account cart).
16. Promo code: valid, expired, already used, letter case, combination with another discount, minimum amount. The error explains the reason.
17. Free shipping above a threshold: the threshold is displayed and works when the total crosses it both upward and downward.
18. If the price or stock changed while the product sat in the cart, the user sees a message instead of finding out at payment.

3. Checkout: ordering without registration (12 checks)

This is where money gets lost. We cover the typical bugs of this stage in detail in Why Orders Get Lost at Checkout: 7 Common Bugs; here is the basic list.

19. An order can be placed as a guest, without mandatory registration.
20. Field validation appears next to the field, not as one message at the top; entered data does not disappear after an error.
21. The phone field accepts +380…, 380… and 0… formats, with spaces and parentheses, and stores them in a single format.
22. An email with a trailing space (a typical result of phone autofill) is handled, not rejected.
23. Cyrillic, apostrophes and quotes in the name and address do not break the order (try O'Connor and Ґанок).
24. Choosing a delivery method changes the cost and the total immediately, without a reload.
25. Pickup shows the address and opening hours.
26. Address: for courier delivery the required fields are mandatory; for a branch they are hidden and do not block submission.
27. Double-clicking "Confirm order" creates one order, not two.
28. The browser's Back button does not reset the form or duplicate the order.
29. After a successful order the customer sees a thank-you page with the order number; refreshing the page does not create a new order.
30. If the session expires in the middle of checkout, the user does not lose the cart.

Add a "slow connection" test here: turn on Slow 3G in DevTools and place an order. That is where buttons without a loading indicator and double clicks show up.

4. Payment and Nova Poshta (10 checks)

Integrations break at the joints between systems, so we test success and every kind of failure. A separate deep dive on this topic: Nova Poshta and Payment Integration: Where It Breaks Most Often.

31. Successful card payment in the sandbox: the order gets the "paid" status and the customer receives an email.
32. Declined card: the order stays "awaiting payment", the customer sees a clear message and can try again.
33. The customer closed the tab on the bank page: the order does not hang, and there is a way to pay again via a link.
34. The payment provider sent the callback twice: the order is not paid twice and emails are not duplicated (idempotency).
35. The callback arrived before the customer returned to the site: the status is still correct.
36. Cash on delivery has its own rules (limits, fees) and is shown correctly in the order.
37. Nova Poshta: city search by part of the name works, and settlements with the same name in different regions are distinguished.
38. Branches and parcel lockers load, search by number works, and a closed branch is not offered.
39. Shipping cost and delivery times match the carrier's tariff, and the waybill (TTN) is created with the correct dimensions and weight.
40. A carrier API error does not block the order: the manager sees that the waybill was not created and can retry.

5. Account and emails (6 checks)

41. Registration, login, password reset: the email arrives, and the link works once and has an expiry.
42. The same email cannot be registered twice, even in a different letter case.
43. Order history shows the correct statuses and amounts.
44. Transactional emails (confirmation, payment, shipping) do not land in spam, look right in Gmail on a phone and contain the correct data.
45. Newsletter signup and the contact form work, and there is consent to data processing.
46. Admin emails contain no personal data that does not belong there, and Telegram or CRM notifications arrive with all order fields.

6. Mobile and compatibility (6 checks)

For most stores more than half of the traffic is mobile, so this is not an "extra".

47. Check widths of 375, 768 and 1440 pixels: no horizontal scroll and no clipped text.
48. Buttons and fields are finger-friendly (roughly 44 pixels or more), and fields use the right keyboard type: tel for phone, email for email.
49. A sticky header or banner does not cover the "Buy" button or the input field when the keyboard is open.
50. iOS Safari: checkout, payment, filters, dropdowns.
51. Chrome on Android, Firefox and Edge on desktop: the main purchase flow.
52. Modals close, focus does not escape behind them, and the page underneath does not scroll.

7. Speed, SEO and security (8 checks)

53. Run Lighthouse on mobile for the home page, a category and a product page. Target: LCP under 2.5 s, CLS under 0.1. We explain how to read these metrics without a developer in Core Web Vitals for Store Owners.
54. Every product and category has a unique title, description, a single h1 and a canonical; filtered pages do not create endless duplicates.
55. robots.txt and sitemap.xml are in place, and the test environment is closed to indexing (and that noindex did not travel to production with the release).
56. Product and BreadcrumbList structured data is present with the correct price and availability.
57. The site works over HTTPS with no mixed-content warnings; http and www redirect to a single version.
58. The 404 page is useful, and old URLs have 301 redirects.
59. Basic security: the password is not passed in the URL, the admin panel is closed and not sitting unprotected at /admin, and forms are protected from spam.
60. Analytics: purchase, add_to_cart and begin_checkout events arrive, and tracking does not fire before consent in the cookie banner.

Don't want to go through 60 checks yourself? We will run a free express check in 48 hours: 10–15 key problems with video and priorities. A full ecommerce QA audit costs from UAH 6,000.

What to do with the results

After working through the checklist you will have a list of problems. Do not try to fix everything at once; sort them by impact.

• Blockers: the customer cannot buy or pay. Fix before launch, no exceptions.
• Critical: there is a workaround, but some customers will leave (a bug only in Safari, a promo code that does not work).
• Significant: they spoil the experience or SEO, but no money is lost.
• Cosmetic: fix when there is time.

A good launch rule: zero blockers and zero critical issues on the "product → cart → payment" path. The rest can launch with a list of known issues and a fix plan.

One more practical tip: after every release, repeat at least 12–15 key checks (sections 2–4). This is called regression testing. If it takes hours of manual work every time, it is worth thinking about automating the most important scenarios. We describe when that pays off and when it does not in Manual vs Automated Testing.

Common mistakes when you test it yourself

In our experience, owners and developers who test their own store make the same mistakes again and again.

• They test the "happy path". Customers do the opposite: they type extra spaces, press Back and close the tab in the middle of payment.
• They test on their own computer. The developer works on a fast laptop with a wide screen, while the buyer is on an old Android phone on the subway.
• They do not record the steps. A bug that cannot be reproduced will not be fixed. Record your screen.
• They do not retest after the fix. Fixing one thing breaks neighboring functionality, so after every fix run through the related checks.
• They skip emails and notifications. The order was created, but the email never arrived, and the customer thinks they were ignored.

If you have a developer, ask them to add a "sandbox" page with all product states, or better still, set up automated tests for the cart and checkout. It is the cheapest insurance against repeating old mistakes.

Need a second pair of eyes before launch? Describe your store in the brief, and we will tell you how much time and money it takes to test your specific project.