UAT Testing Explained: What User Acceptance Testing Is, Who Signs It Off, and What to Check Before Go-Live

UAT means user acceptance testing: the people who will do the job confirm, with their own data and under their own rules, that the system lets them do it before go-live. It is not a bug hunt and not training. Business users run the scripts, a business analyst writes them from the acceptance criteria and triages what fails, and one named process owner signs. Most UAT phases fail before they start: no entry criteria, vendor-written scripts, a demo tenant for an environment, and a sign-off that is a calendar date rather than a decision. This guide covers what UAT is, who signs, how it differs from SIT and QA, what a UAT environment needs, and the sign-off checklist. For the business owner whose name goes on the form.

Introduction

The sign-off email usually arrives on a Thursday. UAT is complete, it says, 212 of 214 scripts passed, please confirm by end of day so that cutover can proceed on Saturday. The person it is addressed to has run none of the scripts, has not seen the two that failed, and is being asked to accept a system on behalf of forty people who will use it on Monday.

If you searched for what UAT means, there is a fair chance you are that person. The short version: acceptance is a decision and testing is the evidence for it, and the email above offers a number in place of both. The rest of this guide is about how to get the evidence, who should produce it, and what has to be true before your name goes on the form.

What is UAT testing?

User acceptance testing is the stage where the people who will do the work confirm that the system lets them do it, end to end, with their data and under their rules, before go-live. UAT stands for user acceptance testing. Every word in it carries weight. User: the person who will do the job on Monday, not a tester, not the vendor, not the project team. Acceptance: a decision to take the system into the business, with whatever conditions attach to it. Testing: the evidence that decision rests on.

Earlier test stages answer a different question. System testing asks whether the software does what the specification says. UAT asks whether the business can run on it. Those come apart more often than people expect: a system can match every line of its specification and still not let a clerk close month-end, because the specification never described month-end.

Three things UAT is not. It is not a bug hunt; if UAT is finding functional defects by the dozen, the earlier stages were skipped and you are paying business staff to do QA's job. It is not training, although it reveals what the training will need to cover. And it is not the vendor's demonstration, however polished, because a demonstration follows the vendor's script and UAT follows yours.

Where do the scripts come from? From the acceptance criteria written when the requirements were agreed. Each criterion becomes at least one script: the setup, the steps the user takes, the expected result. A requirement with no script is untested. A script with no requirement behind it is a wish someone added late. The discipline of checking that the criteria themselves are testable belongs to an earlier stage, covered in requirements verification methods; UAT is where the business finds out whether that earlier work was done.

Key Takeaway: If the people running UAT would not do the job on Monday, it is not UAT. It is system testing with a different name on the invoice.

Who performs and signs off UAT?

Business users who do the work every day execute the scripts, and one named process owner signs. Everyone else supports. The roles are easy to list and routinely confused in practice.

The process owner is the manager accountable for the business process the system serves: the controller for finance, the operations manager for dispatch, the registrar for admissions. They sign, and they decide what happens to every defect still open on the day they sign. The testers are frontline staff drawn from each role that will touch the system, usually three to eight per module, chosen for knowing the exceptions rather than for being available. The business analyst writes the scripts from the acceptance criteria, runs the daily defect triage, keeps the log, and assembles the sign-off pack. The project manager owns the schedule, the environment booking, and escalation. The vendor or development team fixes within an agreed turnaround. IT and QA keep the environment up, refresh data, and run regression after fixes.

The pattern that goes wrong is predictable. The business is busy, so the project team runs UAT "on their behalf." The scripts get executed, the pass rate is high, and a director signs because the pass rate is high. Risk has transferred to the business without any knowledge transferring with it. The version we see most often is a finance manager who signed on the first day of month-end week, discovered on the third day that reversals posted to the wrong period, and learned that the reversal script had been among the 212 that passed, executed by someone who did not know what a correct reversal looked like.

ID Business Analysis Canada staffs this differently through its Delivery & Implementation practice: an embedded business analyst writes the scripts from the acceptance criteria, runs the daily triage, and assembles the sign-off pack the process owner signs, which is how the Woodlands ERP enhancements engagement ran, with the analyst running functional testing and coordinating user acceptance testing with the business users across four release cycles.

Key Takeaway: One name on the sign-off, and it belongs to the person who owns the process, not the person who owns the project.

How is UAT different from SIT and QA?

QA, or system testing, checks the software against its specification. System integration testing, SIT, checks that connected systems exchange data correctly. UAT checks that the business can run on the result. They run in that order, and each one's exit is the next one's entry.

The comparison people search for most is UAT vs QA, and the honest answer is that they find different defects. QA finds the calculation that is wrong. UAT finds the calculation that is right and useless, because the clerk needs the figure before the approval step and the system produces it after. SIT sits between them and is the stage most often squeezed. An integration can pass SIT because both systems agreed on the same wrong tax code; it takes a user who knows the right code to notice.

The order matters for a practical reason. When SIT and UAT run in parallel to save time, business testers become integration testers. They log interface defects they cannot describe, the defect log fills with duplicates, and the real UAT findings get lost in it. Regression testing after fixes belongs to QA, not to the business users, who should re-run only the scripts that failed.

Key Takeaway: UAT starts when SIT exits. Running them together does not save two weeks; it spends the business testers' time on defects they cannot diagnose.

What is a UAT environment?

A UAT environment is a copy of the production configuration, loaded with business-realistic data, connected to the real interfaces or to stubs that behave in known ways, frozen for the duration of the cycle, and accessible to business users under their own roles and permissions. Five properties, and the cycle is compromised when any one of them is missing.

Configuration should match what will go live: the same workflows, approval limits, tax tables, number sequences, and language settings. Data should look like the business: a masked extract of production, or a curated set built to cover the exceptions, which means month-end and year-end records, French-language customer records, multi-currency transactions, the three accounts that always break the rule. Interfaces should be connected to test instances of the real systems; where that is impossible, the stub must return realistic responses, including the failure ones. The code should be frozen for the cycle, with any fix deployed through change control and followed by regression. And users should log in as themselves, with the permission set they will have on Monday, because an administrator account proves nothing about whether a clerk can see the button.

The failure that appears most often is UAT run in the vendor's demonstration tenant: configured for the sales cycle, loaded with tidy data, every tester an administrator. The scripts pass. The business then meets its own data and its own roles for the first time in production.

Entry criteria follow from the five properties, and they are where a UAT plan earns its keep. UAT begins when SIT has exited, the environment meets the five properties, the scripts are approved by the process owner, testers have been walked through the scripts and the defect process, and severity definitions are agreed so that "critical" means the same thing to the business and to the vendor. The visual below places the environment and the entry gate in the full sequence.

Key Takeaway: Test as the users' own roles, on last month's real volumes, in a frozen copy of production. An administrator login in a demonstration tenant is a demonstration, not a test.

What goes in a UAT sign-off checklist?

Evidence that the scripts covered the requirements, that every open defect has an owner and a decision, that the real business cycles ran end to end, and that the person signing has read the exceptions. A UAT test plan defines the scope, scripts, schedule, roles, environment, severity definitions, and exit criteria at the start; the sign-off checklist is those exit criteria, checked. A plan without exit criteria produces a sign-off by calendar.

Seven items, in the order a process owner should read them.

Every acceptance criterion has at least one executed script, and the trace from criterion to script to result is in the pack. Coverage is measured against the criteria, not against the script count, because 214 scripts can leave a dozen criteria untested.

Every critical and high defect is either closed and regression-tested, or accepted in writing with a workaround, an owner, and a date. "Accepted" is a decision the process owner makes, and it belongs on the form.

The business cycles ran end to end: month-end close, the payroll run, the peak day, whatever the process's own rhythm is. Running individual transactions is not the same as running the week.

Testers worked under their own roles and permissions. If any script was executed as an administrator, it is re-run.

Realistic volumes were observed at least once: the batch job on a full month of data, the report on the real customer count, the interface at the daily peak.

The cutover and rollback plan has been reviewed with the business, including who decides to roll back and by what time on cutover day.

The sign-off names the process owner, the date, and the conditions. Conditions are normal. A sign-off with no conditions on a system of any size usually means the exceptions were not read.

Back to the Thursday email. The two scripts that failed are the sign-off. What were they, who decided what to do about them, and does the process owner agree? If the pack answers that in a paragraph, sign. If it answers with the pass rate again, do not.

Key Takeaway: Sign-off is a decision about the open items, not a pass rate. If the signer has not read the defect log, the signature is a formality that moves risk, not evidence.

Frequently Asked Questions

What does UAT mean?UAT stands for user acceptance testing. It is the final test stage before go-live, in which the business users who will operate the system confirm that it supports their process end to end, using realistic data and their own roles. Acceptance is the decision to take the system into the business; the testing provides the evidence for that decision. UAT follows system testing and system integration testing and ends with a signed acceptance by the process owner.

What is the difference between UAT and QA testing?QA testing checks the software against its specification and is run by testers. UAT checks whether the business can run its process on the software and is run by the business users themselves. QA finds the calculation that is wrong; UAT finds the calculation that is right but arrives after the step that needs it. QA should be complete before UAT starts, otherwise business users spend their time logging functional defects that QA would have caught in a fraction of the time.

How long should UAT take?Two to four weeks for a single module with five to eight testers, run as two cycles: the first finds the defects, the second confirms the fixes and re-runs the business cycles. A multi-module ERP program needs six to eight weeks, because the month-end cycle has to run at least once on realistic data. Shorter cycles are possible only when scripts were not all executed, and a UAT that finishes early should prompt a coverage check rather than a celebration.

Who should run UAT if we do not have a business analyst?The process owner still signs and the business users still execute; the gap is the person who writes the scripts, runs triage, and prepares the sign-off pack. ID Business Analysis Canada fills that gap through its Delivery & Implementation practice, embedding a business analyst in the delivery team to write the scripts from the acceptance criteria, run daily defect triage with the vendor, and assemble the evidence the process owner signs against. Otherwise the vendor runs UAT and signs its own work.

Conclusion

The Thursday email asked for a signature on a number. What it owed the signer was a pack: criteria traced to scripts, the two failures with a decision on each, the month-end run, the roles tested as the staff will have them, and a line for conditions. UAT is the last moment the business can refuse a system cheaply. After Saturday, every refusal is a change request.

If a go-live is coming and nobody owns the scripts, the triage, or the pack, ID Business Analysis Canada's Delivery & Implementation practice embeds a business analyst in the delivery team to run UAT the way it is described here: scripts from the acceptance criteria, daily triage, and a sign-off pack built around the exceptions rather than the pass rate. Book a free consultation and bring the UAT plan, or the email that asked you to sign.

Sources

1. ISTQB, Standard Glossary of Terms Used in Software Testing, definitions of acceptance testing and system integration testing.
2. Business Analysis Canada, Woodlands ERP enhancements and support, case study; functional testing led and user acceptance testing coordinated with business users across four release cycles.
3. Business Analysis Canada, Prove It Early: Requirements Verification Methods That Catch Defects Before Build, business-analysis.ca blog, September 2026.
4. Business Analysis Canada, De-Risking the Pivot: Your Essential ERP Data Migration Strategy, business-analysis.ca blog, August 2026.
5. Business Analysis Canada, Adoption Is a Requirement: Change Management for Digital Transformation, business-analysis.ca blog, September 2026.