Retail Software Testing: A Checklist for Omnichannel and E-commerce Teams

How many of the 48 checks below does your stack pass today? That number is a better predictor of your peak season than any load-test report, because retail software fails at the seams – store versus web stock, payment versus order, promo engine versus margin – and most test plans are organised around screens instead.

This is the retail software testing checklist we run against commerce platforms: 48 checks in seven groups, each tagged by severity, each with a one-line way to verify it. It comes from fifteen years of QA for rental subscriptions, retail-operations apps, fulfilment platforms, digital-goods marketplaces and Shopify apps.

Our retail testing services and e-commerce software testing services pages describe what we run for clients; this is the list we run it against. Score yourself, fix the red items first, and keep the list – a one-page version is linked at the end.

Ready to take your software quality to the next level?

Schedule a call

Maximum score: 100. Bands are explained at the end.

Why software testing in the retail domain needs its own checklist

Retail software is different because the same fact – a price, a stock level, a promotion – has to be true in five systems at once, under traffic that arrives on a schedule.

If the vocabulary here is new, our brief guide to e-commerce testing is the primer; this article assumes you have shipped a storefront and want to know what you missed.

Group A — Storefront and search (checks 1–7)

The storefront is where disagreement between systems becomes visible to the customer first.

1. Prove product data matches across web, app, store and marketplaces. 🔴

Why: A product description page (PDP) showing a different price or spec than the marketplace listing is a chargeback or a complaint, every time.

Verify: Nightly reconciliation of SKU, price, attributes and images across every channel feed; diff report with a failing threshold.

2. Test faceted search, sorting and the zero-results path. 🟠

Why: Search is the storefront for most sessions; a facet that returns nothing on a valid combination is an invisible lost sale.

Verify: Golden queries per category re-run after every catalogue or index change; zero-results page offers alternatives and is tracked.

3. Verify price display rules per region: tax-inclusive, currency, rounding. 🔴

Why: Showing a tax-exclusive price in a tax-inclusive market is a legal problem as well as a conversion one.

Verify: A data-driven matrix of region × customer type × product tax class, asserted on PLP, PDP, cart and checkout.

4. Test promotion and coupon stacking rules against the margin model. 🔴

Why: Promo engines are rule tables; unintended combinations are how a "20% off" weekend becomes 45% off.

Verify: Every active rule combination in a data-driven suite with expected final price; new campaigns cannot go live without a passing run.

5. Hit Core Web Vitals targets on PLP and PDP, including PWA offline behaviour. 🟠

Why: The listing and product pages carry the most third-party scripts and lose the most impatient visitors.

Verify: Lab and field metrics per release; if the storefront is a progressive web app, test install, offline shell and cache invalidation – what a PWA is and how it behaves is covered in our progressive web application explainer.

6. Pass WCAG 2.2 AA on the whole purchase path. 🟠

Why: Accessibility failures on checkout are a legal exposure in the US and EU and exclude paying customers.

Verify: Automated scans plus a manual screen-reader run from PLP to confirmation on every release.

7. Test every market's localisation: language, currency, formats, right-to-left. 🟠

Why: A localisation defect is usually a storefront that works perfectly in the headquarters market and nowhere else.

Verify: A real-device and browser matrix derived from analytics per market – how to build and maintain one is in our compatibility testing guide.

War-room note – Grover. Grover rents refurbished technology on subscription – web, iOS and Android, four localisations, more than 1.2 million devices circulated when we started in 2018. Our engineers built 300+ test cases and 600+ automated scripts to 90% coverage. The storefront escape we saw most often was a price or availability that differed in one locale; the localisation matrix has been a release gate ever since. Read the Grover case study.

Group B — Cart, checkout and payments (checks 8–15)

Checkout is where 70% of carts are abandoned on average across Baymard's 49 aggregated studies; a defect here is indistinguishable from friction, and just as expensive.

8. Persist the cart across devices, sessions and login. 🟠

Why: The customer who adds on mobile and buys on desktop is the normal customer.

Verify: Automated journeys: guest → login merge, cross-device, expired session, price change while in cart.

9. Run the checkout funnel end to end on your top five devices every release. 🔴

Why: Checkout is the one flow where a device-specific defect costs money within minutes.

Verify: Playwright/Appium E2E on the five devices with the most sessions, including a real test-card authorisation.

10. Test the PSP integration: 3-D Secure, wallets, BNPL, declines, retries. 🔴

Why: The payment provider is a third party on the critical path; its edge cases are yours.

Verify: Contract tests with recorded responses for every outcome; see our payment gateway testing guide for the full list of what to cover from checkout to confirmation.

11. Prove payment capture and order creation are idempotent together. 🔴

Why: "Charged but no order" and "order but no charge" are the two incidents every retailer has had at least once.

Verify: Fault-injection tests: payment success + order failure, order success + payment timeout, duplicate submit; assert exactly one consistent outcome.

12. Test tax calculation edge cases: thresholds, exemptions, bundles, cross-border. 🟠

Why: Tax services return the wrong answer silently on the cases nobody included in the integration demo.

Verify: A tax matrix per jurisdiction with expected amounts, re-run on every tax-service or catalogue change.

13. Tune fraud rules against false declines, not just fraud. 🟠

Why: A fraud filter that blocks 2% of good customers costs more than the fraud it prevents.

Verify: Replay a labelled sample of historical orders through the current rules; assert both fraud catch rate and good-order approval rate.

14. Test gift cards, store credit and split tender end to end, including refunds. 🟡

Why: Multi-tender refunds are where accounting discrepancies are born.

Verify: Data-driven cases for every tender combination through purchase, partial refund and full refund.

15. Verify order confirmation, email and SMS fire once, in order, within the SLA. 🟡

Why: Duplicate or missing confirmations drive support tickets and chargebacks.

Verify: Event-stream assertions on the notification queue; de-duplication tests on replayed events.

Group C — Stores and POS (checks 16–22)

Retail application testing in the store has one extra constraint the web does not: the software has to keep working when the network does not.

16. Prove POS works offline and syncs on reconnect without duplicates. 🔴

Why: A till that stops when the store's connection drops is a queue to the door.

Verify: Cut the network mid-transaction in the lab; assert the sale completes, queues and syncs exactly once.

17. Test BOPIS, endless aisle and ship-from-store flows across systems. 🟠

Why: Buy-online-pick-up-in-store touches web, OMS, store inventory and the associate app; each hand-off can lose the order.

Verify: E2E journeys from web order to store pick confirmation to customer notification, including cancellation and no-show.

18. Prove store stock and web availability agree within your SLA. 🔴

Why: Inventory distortion – out-of-stocks and overstocks – cost retailers $1.7 trillion globally in 2024, $1.2 trillion of it in out-of-stocks; a large share is stock that exists but the system cannot see.

Verify: Scheduled reconciliation between store inventory and the availability service, with latency measured and a failing threshold.

19. Test associate and store-ops apps on the real device fleet. 🟠

Why: Store devices are older, shared and on worse Wi-Fi than anything in the office.

Verify: A real-device matrix matching the fleet's oldest units; offline and low-signal scenarios in every regression.

20. Validate receipts, tax and fiscal compliance per jurisdiction. 🔴

Why: Fiscal receipt requirements vary by country and change by law; non-compliance is a fine.

Verify: Receipt content assertions per jurisdiction; fiscal-device integration tests where required.

21. Test loyalty lookup, accrual and redemption at the till and online. 🟡

Why: Points that accrue online but cannot be redeemed in store are a programme nobody trusts.

Verify: Cross-channel loyalty journeys with balance assertions after each step.

22. Maintain a peripheral matrix: scanners, printers, payment terminals, firmware. 🟠

Why: A terminal firmware update can break a tender type overnight.

Verify: Inventory of peripheral models and firmware; hardware-in-the-loop smoke test per release – our POS application testing best practices article covers the setup.

War-room note – SimpliField. SimpliField is a mobile platform for retail operations: store teams, tasks, communication and performance data for retail chains. Since 2020 our team of three has built 8,000+ test cases in 20+ suites to 95% coverage and supported about 24 releases with no critical or major defects reaching production. The lesson from store software: the defects live on old devices with bad Wi-Fi, so the real-device matrix and the offline scenarios are where the regression effort goes. Read the SimpliField case study.

Group D — Inventory, orders and fulfilment (checks 23–30)

Once the order exists, the software's job is to get the right thing to the right place – through systems that each think they own the truth.

23. Define one source of stock truth and test every consumer against it. 🔴

Why: Three systems with their own stock numbers will disagree; the question is only when.

Verify: Reconciliation jobs from the source of truth to every consumer (web, store, marketplaces), with sync latency measured.

24. Prove you cannot oversell the last unit under concurrency. 🔴

Why: Flash sales and viral products put hundreds of buyers on one SKU in one second.

Verify: Parallel checkout tests on a single-unit SKU; assert exactly one order and honest messaging for the rest.

25. Test OMS routing rules: split shipments, ship-from-store, partial fulfilment. 🟠

Why: Routing rules decide cost and delivery time per order; a wrong rule is silent margin loss.

Verify: A data-driven matrix of order shape × inventory position → expected routing; run on every rule change. Routing, orchestration and exception flows are the core of our order management system testing work.

26. Assert the order-status event stream customers see is complete and ordered. 🟠

Why: "Shipped" arriving before "confirmed" is the support ticket you can predict.

Verify: Contract tests on the status events: every transition emitted once, in order, with the right payload.

27. Test the WMS integration: pick, pack, ship, short-ship, cancel-in-flight. 🟠

Why: The exception paths – cancellations after pick, short picks – are where orders disappear.

Verify: E2E tests across OMS and WMS for each exception, with stock and order state asserted after.

28. Test carrier label and tracking integrations, including failure modes. 🟡

Why: Carrier APIs rate-limit and go down at exactly the busiest hour.

Verify: Contract tests with recorded failures; graceful queueing when the carrier is unavailable.

29. Prove returns and exchanges update stock, refunds and the customer at once. 🔴

Why: With 16.9% of sales coming back, a return that refunds without restocking – or restocks without refunding – is a daily reconciliation failure.

Verify: E2E return journeys per return reason and tender type, asserting stock, ledger and notification.

30. Test marketplace order ingestion and inventory feeds per marketplace. 🟠

Why: Amazon, eBay and Zalando each have their own order shape, cancellation rules and feed cadence.

Verify: Contract tests per marketplace; feed reconciliation; penalty-rule scenarios (late shipment, cancellation rate).

War-room note – Soapbox. Soapbox is an e-commerce fulfilment and warehouse management platform – multi-storefront management, inventory, order processing, shipping labels and packaging recommendations. Since 2021 our team has written 2,500+ test cases, made regression three times faster, reported 550+ critical bugs and built the mobile QA process from scratch. The pattern: the order-status event stream is the contract customers actually experience, so we test it as a sequence with ordering assertions, not as a set of screens. Read the Soapbox case study.

Group E — Subscriptions, loyalty and the money that keeps moving (checks 31–36)

Recurring revenue turns every billing rule into a calculation that runs thousands of times a month without a human looking.

31. Test billing cycles with proration, pauses, skips and anchor dates. 🔴

Why: Proration errors are small per customer and enormous in aggregate, and customers notice to the cent.

Verify: A data-driven matrix of plan × change date × cycle anchor → expected invoice, with a golden file.

32. Test dunning and retry logic, including card updater and hard declines. 🟠

Why: Involuntary churn is the largest controllable churn in most subscription businesses.

Verify: Scenario tests for every decline code through the retry schedule to cancellation or recovery.

33. Test mid-cycle plan changes: upgrade, downgrade, add-on, credit. 🟠

Why: Every plan change is a proration plus an entitlement change plus a notification.

Verify: E2E per change type with invoice, entitlement and email asserted.

34. Prove entitlements sync to fulfilment and access systems on time. 🔴

Why: A paid subscriber who cannot access, or a lapsed one who still can, is either a complaint or a leak.

Verify: Contract tests from billing events to entitlement services with latency thresholds.

35. Verify loyalty accrual and redemption are consistent across every channel. 🟡

Why: Loyalty balances are a liability on the balance sheet; inconsistency is an audit finding.

Verify: Cross-channel reconciliation of points ledger versus transactions.

36. Reconcile revenue recognition and subscription reporting to the ledger. 🟡

Why: Finance will find the discrepancy at quarter end; better that a test finds it nightly.

Verify: Automated reconciliation between billing events, invoices and the accounting export. Lifecycle, billing and entitlement coverage is the core of our subscription management platform testing.

War-room note – Shops. Shops is a mobile-first platform for selling digital products through affiliate marketing, with five localisations and payments running through Rebilly and a crypto rail. Over two years our two engineers built 500+ test cases, reached 75% regression coverage and supported nine sub-projects to release. Recurring billing × multiple payment rails × five locales is a combinatorial matrix that only data-driven tests can cover; hand-written cases ran out in the first month. Read the Shops case study.

Group F — Shopify and platform apps (checks 37–42)

Auto QA for Shopify has a specific challenge: the host platform ships changes on its calendar, not yours, and over a peak weekend it runs at a scale – $11.5 billion in BFCM 2024 sales, peaking at $4.6 million per minute and 284 million edge requests per minute – that your app inherits whether it is ready or not.

37. Test the app against every supported checkout version and extension point. 🔴

Why: Checkout Extensibility changed what apps can do; a merchant on an older checkout behaves differently from one on the new.

Verify: Regression on test stores pinned to each supported checkout configuration.

38. Prove webhook handling is idempotent and order-independent. 🔴

Why: orders/create, orders/updated and app/uninstalled arrive late, twice and out of order; Shopify documents it, apps still break.

Verify: A webhook replayer that delivers duplicated, delayed and reordered payloads; assert one effect.

39. Test theme compatibility: Online Store 2.0, popular themes, headless (Hydrogen). 🟠

Why: Storefront apps break when a merchant changes theme, which merchants do without notice.

Verify: A theme matrix in the regression suite; visual diff of app blocks per theme.

40. Respect API rate limits and use bulk operations for backfills. 🟠

Why: An app that hits the limit during a merchant's BFCM is uninstalled on Monday.

Verify: Load tests against rate-limit behaviour; bulk-operation paths tested for large stores.

41. Test the Billing API: plan changes, trials, usage charges, refunds. 🟠

Why: Your own revenue runs through someone else's billing system with its own edge cases.

Verify: E2E on development stores for every plan transition.

42. Implement and test the mandatory GDPR webhooks. 🔴

Why: customers/data_request, customers/redact and shop/redact are required for listing and audited.

Verify: Automated tests prove each webhook deletes or exports exactly the right data. Our Shopify app testing page describes how we structure all six of these checks for app vendors.

War-room note – BookThatApp. BookThatApp is the leading Shopify appointment scheduling app, and we have tested it for eight years: 1,000+ automated scripts, over 80% coverage, regression cut from four days to about two hours, OWASP ZAP in the pipeline. The pattern that shaped the suite: the host platform ships changes you did not schedule, so the regression runs on Shopify's release calendar as well as ours. Read the BookThatApp case study.

Group G — Peak season, performance and resilience (checks 43–48)

Peak is not a load test; it is every third party in your stack being slow at the same time while your traffic is ten times normal.

43. Load-test on last year's peak curve plus growth, through checkout and the PSP. 🔴

Why: Flat-concurrency tests miss the ramp; browse-only tests miss the part that makes money.

Verify: A replayed curve from analytics with checkout and payment sandbox included; run at least twice before peak. Tool choice is compared in our guide to load testing tools.

44. Test the waiting room or queue, including unfair-advantage paths. 🟠

Why: A queue that lets direct-URL visitors skip it is worse than no queue.

Verify: Load test with and without the queue; attempt every bypass you can think of.

45. Fail over cache and CDN under load without stale prices or stock. 🟠

Why: The cache that saves you at peak is the cache that shows yesterday's price.

Verify: Chaos tests: evict, fail over and purge during load; assert price and availability freshness.

46. Degrade gracefully when search, reviews, tax or the PSP are slow or down. 🔴

Why: Third parties will degrade at peak; the storefront must still sell.

Verify: Fault injection per dependency with timeouts and fallbacks asserted (e.g., checkout continues without reviews; tax falls back to cached rates with a flag).

47. Test flash-sale inventory and promo-code concurrency at peak rates. 🔴

Why: Everything in check 24 and check 4, at a thousand times the rate.

Verify: Spike tests on a single SKU and a single code; assert no oversell, no over-redemption.

48. Alert on business metrics – orders per minute, payment success rate – not only CPU. 🟠

Why: The incident that costs the most is the one where servers are healthy and nobody is buying.

Verify: Synthetic orders every few minutes through peak; alerts on conversion and payment-approval drops; a drill before peak.

Test automation in retail: which checks to automate first

Test automation in retail pays back fastest on the checks that run most often and fail most quietly – the integrations and the reconciliations – not on the storefront UI.

What stays manual: visual merchandising review, first-time localisation of a new market, and the store associate's experience on the shop floor, which no emulator reproduces.

What your score means — and when to call an e-commerce testing company

Add your points (🔴 = 3, 🟠 = 2, 🟡 = 1; maximum 100) and read the band honestly.

85 or more. You are peak-ready. Keep the suites in CI, re-score every quarter, and treat any new integration as a new row in the checklist before it goes live.

60 to 84. Fix every 🔴 before the next release and every 🟠 before peak. In our experience this is a six-to-ten-week effort for one or two QA engineers who know commerce – in-house if you have them, outsourced if you do not. The work is mostly building contract tests and reconciliation jobs, not writing UI scripts.

Below 60. The stack is carrying risk nobody can see, and peak will find it. This is where e-commerce QA testing outsourcing makes sense – not permanently, but to build the suites, the device lab and the reconciliation jobs, run one peak together, and hand over. When choosing an e-commerce testing company, ask for four things: retail and commerce case studies with numbers, a real-device lab you can see, contract-testing experience with the specific PSP/OMS/WMS vendors you use, and willingness to prove it on one flow before you commit. We work exactly that way, and the proof of concept is free.

Peak-readiness timeline

Conclusion

Three checks fail more often than any others in the stacks we score: stock parity across channels (18, 23), payment-and-order idempotency (11) and webhook ordering (26, 38). None of them is visible on a screen, which is why screen-first testing misses them and why this list is organised by where the data moves rather than by what the customer sees. Score your stack, fix the red items, and run the timeline — peak season is the one deadline that never slips.

The one-page checklist (checkbox, severity, points, notes) is available as a Google Sheet linked below the article. If you would like help with the hardest items, talk to us about a free proof of concept on one check: a stock-parity reconciliation across your channels, or a checkout end-to-end suite on your top five devices.

Book a strategic QA consultation

Schedule a call

FAQ

What is retail software testing?

Retail software testing is the verification of the systems that sell, fulfil and account for merchandise across channels — storefronts, checkout and payments, POS, inventory and order management, fulfilment, returns, subscriptions and marketplace and platform integrations — with emphasis on data consistency between systems, promotion and pricing logic, real-device coverage for stores, and performance under scheduled peak demand.

What should an e-commerce testing checklist include?

Seven areas: storefront and search (data parity, pricing rules, promotions, performance, accessibility, localisation); cart, checkout and payments (device coverage, PSP integration, idempotency, tax, fraud, tenders); stores and POS (offline, BOPIS, stock parity, devices, fiscal compliance); inventory, orders and fulfilment (source of truth, overselling, OMS routing, WMS, carriers, returns, marketplaces); subscriptions and loyalty; platform apps such as Shopify (checkout versions, webhooks, themes, rate limits, GDPR); and peak resilience (load, queueing, caching, graceful degradation, business-metric alerting).

Which agencies offer rapid testing frameworks for new retail features?

Look for a partner with commerce case studies showing regression times in hours rather than days, an existing library of contract tests for common PSP, OMS, WMS and marketplace APIs, a real-device lab for store and mobile coverage, and a proof-of-concept offer on one feature before any contract. DeviQA fits that description — our Shopify and fulfilment clients run full regression in two to four hours — and the first flow is free.

How do you test omnichannel inventory accuracy?

Define one source of stock truth; build a scheduled reconciliation from it to every consumer (web availability, store systems, marketplaces) that measures both discrepancy and sync latency against an SLA; run concurrency tests on single-unit SKUs to prove you cannot oversell; and test every exception path — cancel after pick, short pick, return — for its effect on stock.

How do you test a Shopify app?

Against every supported checkout configuration on pinned test stores; with a webhook replayer that delivers duplicated, delayed and reordered payloads; across a theme matrix including Online Store 2.0 and headless; under API rate-limit load with bulk operations for large stores; through every Billing API plan transition; and with automated tests for the three mandatory GDPR webhooks.

When should a retailer outsource e-commerce QA?

When the checklist score is below 60 and peak is on the calendar; when the stack has more integrations than the in-house team has contract tests; or when regression takes days and releases are being skipped to avoid it. The goal of outsourcing is to build the suites, the device lab and the reconciliation jobs and hand them over — not to rent testers indefinitely.

About the author

Dmitry Reznik

Chief Technology Officer

Dmitry Reznik is the Chief Technology Officer and co-founder at DeviQA, bringing deep technical expertise across software architecture, implementation, and long-term system operation.