# User Acceptance Testing for Shopify Projects: A UAT Process

> A user acceptance testing process for Shopify projects: what the client tests, the preview setup, how to triage feedback, and how to reach sign-off.

_Published: 2026-10-09 · CommerceCopilot_

## The review link is not a UAT process

Most Shopify agencies run user acceptance testing by accident. The build passes internal review, someone sends the client a preview link with "let us know what you think," and whatever happens next gets called UAT. Usually one of two things happens: silence until launch week, when problems surface at the worst possible moment, or a long email thread that mixes one real defect with four feature requests and a debate about the shade of the buttons.

Neither failure means the client is bad at testing; it means nobody told them what to test, where, what counts as a problem, or when the window closes. User acceptance testing is a process you hand the client, not a courtesy period you leave open. This post covers a version that fits how Shopify projects actually ship.

## What user acceptance testing is, and what it is not

User acceptance testing is the phase where the client verifies that the build does what their business needs, against the conditions both sides agreed to before the work started. In a standard UAT process for web projects it is the last gate before launch: the agency's internal QA confirms the build works, then UAT confirms it is the right build, then it ships.

That ordering carries the two boundaries that keep UAT useful:

- **UAT is not bug hunting.** Finding broken variant selectors and layout glitches is your team's job, before the client ever gets a link. That pass has its own process, covered in our [Shopify project QA checklist](/blog/shopify-project-qa-checklist). A client wading through bugs your team could have caught is losing confidence with every one they file.
- **UAT is not a second design round.** The time to debate the layout was the design review. UAT checks whether the agreed thing was built, which only works if someone wrote down what was agreed.

On agency work UAT is also a contractual moment: the point where "the project is done" stops being the agency's opinion and becomes a shared, recorded decision.

## A UAT process clients can actually follow

Six steps. The first two happen before the client is involved at all.

### Decide what pass means before the build starts

UAT verifies the build against expectations, so the expectations have to exist in writing first. That is what acceptance criteria are for: per-ticket, checkable conditions that someone who was not in the client call can verify. If your tickets have them, the UAT script is nearly free, because every criterion is a test the client can run in their own words. If your tickets say "improve the product page," UAT will be an argument. We cover the format in [how to write acceptance criteria for Shopify tickets](/blog/writing-acceptance-criteria-shopify-tickets).

### Run your own QA pass first

Never let UAT be the first time anyone tests the build. Run the internal checklist, fix what it catches, and only then schedule the client. The client will give you a few focused hours of testing attention at best. Every bug they hit that your team could have caught costs you twice: once in the fix, and once in how skeptically they read the rest of the build.

### Set up an environment the client can use without help

On Shopify projects the natural UAT environment is an unpublished theme on the client's own store, because it carries their real catalog, apps, and settings rather than demo data. Shopify lets you share a visitor preview link for an unpublished theme that works without a login, with one operational detail: those links expire two days after they are created. Send the link on Monday for testing "sometime this week" and by Wednesday the client is looking at a dead URL, which reads to them as a broken build. Generate a fresh link when the testing window actually opens.

If checkout is in scope, decide up front how the client will test it. Shopify's Bogus Gateway simulates transactions on a development store, and stores on Shopify Payments can enable test mode and pay with test card numbers. One warning applies double here because UAT runs on the client's live store: while a payment provider is in test mode, real customers cannot place orders. Agree on a short, scheduled window, or keep checkout testing on a development store.

### Hand them a script, not a link

"Take a look and tell us what you think" produces feedback about whatever the client happened to click. A UAT script produces coverage. Write scenarios in the client's language, one row each, straight from the acceptance criteria:

- Find the bestseller collection, open a product, switch to a sold-out size, and confirm the notify-me button appears.
- Add two items to the cart, change one quantity, and confirm the free shipping bar updates without a reload.
- In the theme editor, hide the promo block on the new section and confirm the layout holds.

Each scenario names what to do and what should happen, so "it failed" means something specific. Assign scenarios to the right people: the merchandiser tests the theme editor flows they will live in after handoff, the operations person tests the order flow, the founder does not have to test everything. Ten to twenty scenarios covers most Shopify builds; past that, clients skim, and skimming defeats the point.

### Collect feedback in one channel, and triage it

One channel, whether that is a shared sheet, a board, or a form, and a required shape for each item: what you did, what you expected, what happened instead, on which device. Our guide to [writing bug reports developers can fix](/blog/how-to-write-a-bug-report-developers-can-fix) translates directly to client findings; send them the short version of that format with the script.

Then triage every item into one of three buckets before anyone starts fixing:

- **Defect:** the build violates a written acceptance criterion. Fixed inside the project, no discussion needed.
- **Change request:** the build matches the criteria, but the client now wants something different. Valid, and scoped and quoted as new work.
- **Question:** not a finding, just something the client did not understand. Answered, and often a sign the handoff documentation needs a line.

The triage only stays calm because the criteria exist. Without them, every item becomes a negotiation about what was promised.

### End with a decision, not a fade-out

UAT needs a closing date and a named outcome. Timebox the window when you schedule it, and when it closes, call the result: pass, pass with a punch list (launch proceeds, listed defects get fixed by an agreed date), or fail (material defects block launch, fix and rerun the affected scenarios). Record the outcome in writing, even if it is two sentences in an email the client confirms; that record is what you point to when a "bug" reported three weeks after launch turns out to be a change request.

## Where UAT goes wrong

- **UAT as the first QA pass.** The client becomes the bug finder, trust erodes, and real acceptance questions never get asked.
- **No deadline.** An open-ended window means testing never quite starts, the project drifts, and the team that should be on the next sprint is on standby.
- **Feedback in five channels.** One finding in email, one in Slack, two in a call, one in a text to the account manager. Half get lost and resurface after launch as complaints.
- **The whole client team free-testing with no script.** Ten people clicking randomly produces duplicate reports, contradictory opinions, and no coverage of the flows that matter.
- **Treating every finding as in-scope.** Agencies that fix every UAT item to keep the client happy teach the client that UAT is a free revision round, and fund it from margin.
- **No recorded outcome.** If nobody can point to the moment the client accepted the build, the project is never really done, and neither is the invoice conversation.

## Scripts are cheap when the criteria already exist

Everything above leans on one input: acceptance criteria written before the build. That is the expensive part at agency volume, because the senior person who writes sharp criteria is the same person who is busiest when three projects hit UAT in the same month.

That translation step is the core of what CommerceCopilot's Business Analyst agent does: it turns discovery calls, Slack threads, and briefs into tickets with acceptance criteria already structured as checkable lines, with a human reviewing every draft before it reaches the tracker. Those same lines then do double duty downstream. The QA agent runs automated browser testing against them on a [connected store](/docs/shopify) before any review link goes out, and the criteria read back in client language as the UAT script, so the client walks through the same conditions the work was built and tested against. One definition of done, checked three times by three different parties, instead of three definitions discovered to disagree at launch.

## FAQ

### What is the difference between QA and user acceptance testing?

QA is your team verifying the build works: functionality, devices, performance, regressions. UAT is the client verifying the build is right for the business, against the agreed criteria. QA finds bugs; UAT finds mismatches between what was built and what was needed. Run QA first, always, so UAT attention goes to the second question.

### Does a generic UAT process for web projects work for Shopify builds?

The skeleton transfers: criteria first, internal QA, scripted scenarios, single feedback channel, recorded outcome. What changes is the environment layer. Shopify gives you unpublished theme previews on the client's real store, visitor preview links that expire after two days, test orders through the Bogus Gateway or Shopify Payments test mode, and a theme editor the client's team must test as merchants, not just as shoppers. A generic process that ignores those runs UAT against the wrong surface.

### How long should the UAT window be?

Long enough for the assigned people to run their scenarios twice, short enough to stay scheduled rather than ambient. For a typical theme build or feature project, a defined window of a few business days with a named end date works better than a long open one; the deadline is what gets testing onto the client's calendar at all. Scale it to the scenario count, not the project's total size.

### What if the client says they don't have time to test?

Shrink the ask instead of dropping it. Cut the script to the highest-risk scenarios, assign each to one named person, and offer a guided session where someone from your team drives a screen share while the client confirms each outcome. A thirty-minute guided pass beats silent acceptance, because silence is not acceptance; it is deferred feedback, and it defers to the week after launch.

---
Canonical page: https://www.commercecopilot.ai/blog/user-acceptance-testing-shopify-projects