User Acceptance Testing: Why Developer QA Is Not Enough to Launch Your Store

Every launch we have run has a moment, usually a week or two before go-live, when the development team is confident the site is finished. Every ticket is closed, every page has been checked on a phone, test orders go through. And then someone from the client's warehouse, finance or customer service team sits down with the store for an afternoon and finds something the build team had no way of knowing about.

That afternoon is user acceptance testing. It is the cheapest insurance on any ecommerce project, and the part most often squeezed when the schedule slips. This article covers what UAT is, what developer QA cannot catch, who on your team should test, what to cover on an ecommerce launch, and how to run it so it actually protects you.

What Is User Acceptance Testing?

User acceptance testing is the final phase of testing, in which the people who will actually use a system check that it supports their real work before it goes live. In the formal language of the testing standards bodies, acceptance testing determines whether a system satisfies its acceptance criteria and lets the users or customers decide whether to accept it. In plain terms: the business, not the developer, decides whether the store is ready.

It sits at the end of a sequence. Developers test their own code as they write it. A QA specialist then tests the features against the specification and checks that nothing else broke. UAT comes last, and it asks a different question.

	Developer and QA testing	User acceptance testing
Question it answers	Does the site do what the specification says?	Can our business run on this site?
Who tests	The agency's developers and QA team	Your staff, and ideally a few real customers
What they test with	Test accounts, sample products, made-up names	Real customers, real products, real orders from last month
What it finds	Broken features, layout bugs, regressions	Missing rules, wrong assumptions, workflows nobody wrote down
Who signs off	The agency	You

Microsoft's implementation guide for its Dynamics 365 ERP describes the same sequence and is unusually direct about the last step: UAT is always a manual test, done by business users in an integrated test environment, using customer data including migrated data, and it is the closest test to running live operations. Its example testers are order processors, accountants and shippers, not executives. (Microsoft Learn)

None of this moves testing from the agency to the client. Our developers and QA team test every feature, every device and every integration first, and fix what they find, before your team sees the site. UAT is an extra layer on top of that work, not a replacement for it, and it exists because some questions can only be answered by the people who run the business.

Late Defects Cost More, but Be Wary of the "100x" Figure

Bugs found after launch usually cost more to fix than bugs found before it, but how much more depends on the system and on what breaks. You will often read that a bug found after launch costs 100 times more to fix than one caught early, usually credited to the "IBM Systems Sciences Institute". That figure has been traced back to a 1987 textbook citing internal IBM course notes, with no surviving study behind it (The Register, 2021). The better source is Barry Boehm and Victor Basili's 2001 review in IEEE Computer, which found post-delivery fixes often 100 times more expensive on large systems, but closer to 5 to 1 on small, non-critical ones.

For an ecommerce store the honest answer is that it depends what breaks. A typo found after launch costs the same to fix as one found before. A checkout that rejects a payment method, an ERP sync that drops orders, or tax charged wrongly for a month costs lost sales, manual cleanup and customer trust, on top of the fix. UAT is aimed squarely at that second kind of problem.

What Can Developer QA Not Catch?

Developer QA cannot catch anything that lives only in your team's heads, your data or your daily routine. A good QA process catches most other defects. A specification is a summary of how your business works, written by people who were trying to remember everything. UAT is where the summary meets the real thing. Three examples from our own projects, with the clients left unnamed:

The loyalty reward nobody on the build team could redeem

When a beauty brand moved to Shopify's new one-page checkout, we rebuilt their cart validation rules and tested them thoroughly. The client's team found within days that reward products, the items customers redeem with loyalty points, broke the new validation. Our test plan had not included loyalty redemptions, and nobody on our side had a points balance to try one with. The client loaded points onto a test account, we reproduced the problem, and the client gave us the business rule we had been missing: one reward per order, and only alongside a paid product. We built the validation and added loyalty redemption to our checkout test plans from then on. The same round of testing surfaced an affiliate tracking script from the old checkout that was not on anyone's list. Both gaps were closed before the new checkout went live, because the client's team tested the way their customers actually shop.

The ERP that rejects an apostrophe

A B2B distributor's ERP accepted a maximum of 50 characters in every field and no special characters in name fields. Shopify accepts both happily. A developer filling in a checkout as "Test User" will never trip that rule; a customer named O'Brien ordering for "Smith & Sons" will, and the order then fails silently on its way into the ERP. The limit came from the client's operations team, who knew it from years of rekeying orders by hand. We added validation at checkout, but only because someone who works with the ERP every day was in the room.

The gift card that worked in testing

An apparel brand wanted to offer a gift card as a gift with purchase. Our developer's first check passed. When the client's merchandising team set it up the way they actually would, the order stopped at checkout with an "unpurchasable product" error. We reproduced it on their setup, and Shopify support confirmed that checkout had started rejecting gift cards whose price had been set to zero, a platform change with no public announcement. We rebuilt the approach before the promotion ran. Testing on the client's real configuration, by the people who would run the promotion, is what caught it.

The pattern is the same in all three. Each issue depended on something only the business knew: how the loyalty programme works, what the ERP will accept, how merchandising actually sets up a promotion. That is why the agency's testing and the client's testing are both needed, and why neither can stand in for the other.

Why Does UAT Have to Be Your Team?

UAT has to be your team because the scenarios that matter depend on knowledge only your staff have, and because accepting the site for launch is your decision. It is tempting to treat UAT as something the agency does and the client approves. The agency should do its own thorough testing first, but it cannot do your acceptance testing for you, for three reasons.

• The build team tests against what was specified. A thorough QA team tests the edge cases it knows about. Your customer service team knows the ones nobody wrote down, because they hear about them from customers every day.
• The rules that matter most are the ones nobody wrote down. Which customers can skip the minimum order. Which products never ship to Canada. What finance needs on an invoice for a tax-exempt buyer. These surface when the person who applies the rule tries to do their job on the new site.
• Acceptance is a business decision. Launching means accepting the risk of whatever has not been found yet. Only you can decide which known issues you can live with on day one.

This is where buy-in comes in. UAT takes real hours from people who already have full-time jobs, usually at the busiest point in the project. If the leadership sponsoring the project does not explicitly free up that time, testing gets done in gaps between other work, on the happy path, by whoever is available. That is the version of UAT that lets problems through.

Who should do UAT?

Pick people by what they do, not by seniority. A senior manager clicking through the homepage is a demo, not a test. For a typical mid-sized ecommerce launch:

• Customer service: account login, order lookup, returns, the questions customers actually ask.
• Operations or warehouse: orders arriving in the ERP or warehouse system, split shipments, backorders, tracking emails.
• Finance: tax, refunds, payouts, invoices, payment terms.
• Merchandising and marketing: setting up a real promotion, a gift with purchase, a product launch; checking that analytics and ad tracking report sales correctly against real orders.
• For B2B, sales reps and two or three friendly customers: placing a reorder with their own price list, their own ship-to locations and their own payment terms.

Name one UAT owner on your side who tracks progress, chases testers and makes the call on what is a blocker. On our projects that person works directly with our project manager every day during the UAT window.

What Should You Test Before an Ecommerce Launch?

Test every way your business takes, fulfils, refunds and accounts for an order, using real orders from the last three months. Shopify's own Plus launch checklist tells merchants to place test orders with discount codes, logged-in and logged-out customers, different payment methods, shipping rates and addresses, and failed transactions, and to run refunds and the full fulfillment workflow through the ERP. That is the minimum. Build the rest of the scenario list from what your business actually does, not from the feature list. The quickest way is to pull a sample of real orders from the last three months, including the awkward ones, and replay them on the new site. A starting checklist:

Orders and checkout

• Every payment method you accept, including wallets, gift cards, store credit and any financing option
• Discount codes, automatic discounts and gifts with purchase, alone and combined
• Tax for each region you sell into, including tax-exempt customers
• Shipping rates and delivery options, including heavy, oversized and restricted items
• Pre-orders, backorders, subscriptions and bundles if you sell them

After the order

• The order arriving correctly in your ERP, warehouse or 3PL, with the right SKUs, prices and addresses
• Partial shipments, split shipments and cancellations
• Refunds and exchanges, and that they reach finance correctly
• Every customer email and SMS: order confirmation, shipping, delivery, refund, account invite

Customers and accounts

• Migrated customers logging in for the first time
• Order history visible after migration
• Loyalty points, store credit and saved addresses carried over

B2B, if you sell wholesale

• Each customer group seeing the right catalog and prices
• Payment terms, credit limits, minimums and quantity rules
• Multiple buyers and locations under one company account
• Quick order and reorder from history

Marketing, tracking and search

• Analytics and ad platform conversions matching actual orders
• Email and SMS sign-up flowing into your marketing platform
• Redirects from your old URLs (see our migration SEO guide)

For B2B launches, the number of combinations is where the effort goes. Every customer group with its own catalog, price list and terms is another set of test cases, which is why we call testing the most underestimated phase of a B2B replatform.

How Do You Run UAT So It Works?

Plan it at kickoff, test real scenarios on a staging store that behaves like production, triage every finding, retest the fixes and sign off in writing. Step by step:

1. Plan it at kickoff, not at the end. Put the UAT window in the project plan with named testers and blocked calendar time. Agree the acceptance criteria then, while nobody is under deadline pressure.
2. Write scenarios, not features. "A returning wholesale customer in Ohio reorders last month's order, adds one item, and pays on net 30" is a scenario. "Test the cart" is not. Each scenario has steps, an expected result and a column for pass or fail.
3. Test on a copy that behaves like production. A staging store with your real products, real customer data and the real integrations connected in test mode. Testing on sample data hides exactly the problems UAT exists to find. The cautionary tale is the UK bank TSB, whose 2018 migration failure was traced in part to testing only one of two data centres that turned out to be configured differently despite being specified as identical (Slaughter and May review).
4. Start only when the build is ready. UAT on a half-finished site wastes your team's limited hours on bugs QA should have caught. The agency's QA should be complete and the known-issues list shared before your team starts.
5. Log everything in one place, with a screenshot. A shared tracker, not scattered emails. "It gave an error" cannot be fixed; a screenshot, the steps and the order number can.
6. Triage every finding into four buckets. Blocker (cannot launch), must fix before launch, can fix after launch, and change request (new scope, not a defect). Agreeing the buckets in advance stops new feature ideas being argued as bugs at the last minute. A bug is behavior that differs from what was agreed. A change request is something new. Every change accepted during UAT is another chance to break something that already passed.
7. Retest the fixes, and what is next to them. A fix to checkout validation can break something else in checkout. The tester who found the issue confirms the fix.
8. Sign off in writing. A short document stating which scenarios passed, which known issues are accepted for launch, and who approved it.

Plan on UAT taking one to three weeks depending on the size of the launch, plus time for fixes and retesting. A simple storefront redesign sits at the short end; a B2B replatform with an ERP integration sits at the long end.

Why Does UAT Fail?

UAT usually fails for one of five reasons, and all five are about time and people rather than technology:

• It is squeezed. The build runs late, the launch date does not move, and testing absorbs the difference. Hershey's 1999 ERP go-live is the classic example: a schedule compressed to beat Y2K, a big-bang launch going into Halloween season, and about $100 million of orders it could not fulfil (CIO).
• Nobody has time. Testers are asked to fit it around their normal job during the busiest weeks of the project.
• The wrong people test. Managers approve the look and feel; nobody who processes orders touches it.
• Everyone tests the happy path. One standard order, one standard customer, no returns, no B2B terms.
• It is treated as a formality. "It looked fine in the demo" is not acceptance.

What Should Your Agency Bring to UAT?

The agency owns the quality of the build: full QA and regression testing before UAT starts, and fixing everything UAT finds. Your team owns the acceptance decision, and the agency's job is to make that as easy as possible. On our projects that means a written UAT plan with scenarios built from your real order types, a staging store configured to mirror production, a single tracker for findings, a daily check-in during the UAT window, and fixes turned around fast enough that testers can retest while the scenario is fresh. Ask any agency you are considering to show you what their UAT plan looks like before you sign.

Questions to Ask Before You Sign

• Where is UAT in the project plan, and how long is it?
• Will you provide the test scenarios, or are we expected to write them?
• Will we test on a staging store with our real data and integrations connected?
• How will findings be logged and triaged, and who decides what is a change request?
• How quickly are fixes turned around during the UAT window?
• What does sign-off look like, and what happens to issues accepted for after launch?

Planning a Launch or Replatform?

We build the UAT plan into every project from kickoff, with scenarios drawn from your real orders. See how we approach platform migrations and Shopify B2B builds, or talk to us directly.

Frequently Asked Questions

What is user acceptance testing (UAT)?

User acceptance testing is the final phase of testing before launch, in which the people who will use a system day to day check that it supports their real work. For an ecommerce store that means your customer service, operations, finance and marketing staff running real-world orders on a staging copy of the site and signing off that the business can run on it.

What is the difference between QA and UAT?

QA checks that the site does what the specification says, and is done by the agency's developers and testers. UAT checks that your business can run on the site, and is done by your own staff using real products, customers and order scenarios. QA finds broken features; UAT finds missing rules and wrong assumptions.

Who should perform UAT on an ecommerce project?

The people who do the work: customer service, warehouse or operations, finance, merchandising and marketing, and for B2B, sales reps and a few trusted customers. Name one UAT owner on your side to coordinate testers and decide what counts as a blocker.

How long does UAT take?

For a mid-sized ecommerce launch, plan one to three weeks of testing plus time for fixes and retesting. A storefront redesign sits at the short end; a B2B replatform with an ERP integration sits at the long end.

Can the agency do UAT for us?

The agency should prepare the plan, the scenarios, the staging store and the tracker, and complete its own full QA before UAT starts, then fix what UAT finds. It cannot do your acceptance testing for you, because the scenarios that matter depend on knowledge only your team has, and accepting the site for launch is a business decision only you can make.