User Acceptance Testing for Online Stores: A Practical Guide

Ecommerce user acceptance testing, often called UAT, is the stage where people from your business check that a new store, feature or major change works the way the business needs before you accept it and go live. Developers test that the code works; UAT tests that the store works for your customers, products, prices, orders and processes. It is the last chance to find problems cheaply. A structured UAT, with real scenarios, clear roles and a simple way to record issues, prevents most of the unpleasant surprises that otherwise appear in the first week after launch, when customers find them for you instead.

What UAT is, and what it is not

A store goes through several kinds of testing. Developers run technical tests on code. Testers check functions against specifications. Performance tests check speed and capacity. UAT is different: it is the business confirming that the delivered store does what it needs in real situations.

Think of it as a dress rehearsal. The store is finished, the people who will run it walk through real situations, and anything that would embarrass you on opening day is caught while it is still easy to fix.

UAT is not a search for every possible bug, and it is not a design review where new ideas are added. It answers one question: can we run our business on this store? The UK government's service manual describes this kind of practical, regular quality assurance and testing as part of delivering any service well.

Who should take part

Choose testers who know how the business works and who will use the store every day. Each brings a different view of what "working" means:

• Merchandising or product team: catalogue, prices, promotions and content.
• Customer service: orders, customer accounts, returns and refunds.
• Operations and warehouse: order flow, picking, shipping and stock.
• Finance: payments, invoices, taxes and reports.
• Marketing: tracking, emails, landing pages and SEO basics.
• A product owner who coordinates testing and makes decisions.

Include at least one person who has never seen the new store. Fresh eyes notice confusing labels and missing information that the project team has stopped seeing. Give testers time. UAT squeezed around normal work is usually rushed and misses problems. Block out dedicated days in calendars, and make sure managers support testers stepping away from their normal duties for those days.

What to test

Base scenarios on how customers and staff actually use the store. A useful structure:

Do not forget the people behind the scenes. Finance should check that a day's orders appear correctly in the accounting system; the warehouse should pick and pack test orders from real printouts; customer service should practise finding an order, changing an address and issuing a refund. These checks often reveal more launch-day problems than the storefront itself.

Include edge cases that happen in real life: an order with a discount and free delivery, a product going out of stock mid-checkout, an address in a remote area, a partial refund. Our online store launch checklist lists many of the checks worth turning into scenarios.

Writing good test scenarios

Each scenario should be clear enough that anyone in the team can run it and agree whether it passed:

1. Title: "Guest buys a sale item with a discount code and pays by card."
2. Starting point: which product, which customer type, which device and which browser.
3. Steps: what the tester does, in order.
4. Expected result: what should happen at the end, including emails and order status.
5. Actual result: what did happen.
6. Pass or fail, with notes and screenshots for failures.

Keep the language plain and the steps short, so testers spend their time testing rather than deciphering instructions. Prioritise scenarios. Those that cover the most common journeys and the highest-value processes, such as checkout and order flow to the warehouse, should be tested first and most thoroughly.

Recording and prioritising issues

A single, shared list prevents issues being reported by email, chat and phone and then lost. Use one shared place for issues, such as a simple tracker or spreadsheet. For each issue record what happened, the steps to reproduce it, screenshots, the device and browser, and the scenario it came from. Rate severity consistently:

• Critical: stops orders, payments or fulfilment. Must be fixed before launch.
• Major: a key process is wrong or very difficult. Usually fixed before launch.
• Minor: an inconvenience with a workaround. Can be scheduled after launch.
• Cosmetic: visual details. Fixed when time allows.

Retest every fix before closing the issue, ideally by the person who reported it, and check that the fix has not broken anything nearby. Separate genuine defects from new requests. "The discount does not apply" is a defect; "could we also add a loyalty scheme?" is a new requirement for later.

Deciding go or no-go

Agree the criteria before testing begins, for example: all critical and major issues fixed and retested; every payment method tested end to end; orders reaching the ERP correctly; redirects tested; no unresolved data problems. When the criteria are met, the product owner signs off. When they are not, the launch moves or the scope is reduced. Clear criteria remove the pressure to launch on hope. Write the decision down with the date, the open issues and who agreed, so everyone understands what was accepted and what will follow after launch.

Planning ecommerce user acceptance testing

Good UAT starts weeks before testing begins. Build it into the project plan from the start.

Link scenarios to requirements

Every requirement agreed at the start of the project should have at least one scenario that proves it works. If you wrote a requirements document, such as one based on our ecommerce website requirements checklist, use it as the source for your scenarios. This keeps testing focused and makes sign-off objective.

Prepare the environment and data

Testing needs a staging site that matches live as closely as possible: the same extensions, integrations and settings, with realistic products, prices, customer groups and stock. Arrange test accounts with payment providers, carriers and the ERP, so full journeys can be tested without affecting real customers or finances.

Schedule time for fixes

Plan at least two rounds: an initial test, a period for fixes, then retesting. Projects that schedule only one round usually find problems with no time left to solve them. Our guide to ecommerce project timelines explains why testing time should be protected.

Brief the testers

Run a short session explaining the scenarios, how to record issues and how severity is rated. Testers who understand the process find more useful problems and report them more clearly.

Migrations need extra checks

If you are moving from an old store, include scenarios for migrated data and redirects: old customers logging in, past orders visible, reviews on the right products and old URLs reaching the right new pages. Our guide to migrating without losing SEO covers the redirect side.

Common UAT mistakes

• Testing only the happy path. Real customers mistype cards, change their minds and use old browsers. Test what happens when things go wrong.
• Testing on one device. Most shoppers use phones; test key journeys on several real devices.
• Using too little data. Five sample products will not reveal problems with filters, search or performance on a large catalogue.
• Mixing defects and wishes. New ideas during UAT delay launch; record them for a later phase.
• Not testing integrations end to end. An order that looks fine in the store but never reaches the warehouse is a critical failure.
• Signing off under pressure. Launching with known critical issues usually costs far more than a short delay.

Testing after launch

UAT does not end at go-live. The live environment always differs slightly from staging, with real payment keys, real email delivery and real traffic. Place a real order on the live store immediately after launch, check emails and order flow, and monitor closely for the first weeks. Keep the UAT scenarios: they become a regression checklist to rerun after future updates, theme changes and new extensions. A short version covering the most important journeys can be run in an hour before every release, which catches many problems before customers ever see them.

Frequently asked questions

Planning a launch or major change? Talk to our team about structured testing plans and UAT support for your store.