Testing, Validation & Quality Assurance

User Acceptance Testing (UAT)

18 min Lesson 5 of 10

User Acceptance Testing (UAT)

No matter how thorough a development team's internal testing is, the system is ultimately judged by one group of people: the business users who must do real work with it every day. User Acceptance Testing (UAT) is the formal phase in which those users evaluate whether the delivered system truly meets agreed business requirements before it goes live. It is the last quality gate before production — and it is entirely different in character from the developer-owned tests that precede it.

A UAT session is not a bug hunt. By the time UAT starts, the development team should have already found and fixed the technical defects. UAT asks a different question: "Does this system let us do our jobs the way we actually need to do them?" That question can only be answered by the people who know the business best.

Why UAT Is a Business Analysis Responsibility

The systems analyst is the bridge between business and technology. From the business side, the analyst helped define what the system should do; from the technical side, the analyst helped communicate those requirements to the developers. At UAT, the analyst plays a co-ordinating role: preparing the test scenarios, recruiting and briefing the right business participants, managing defects that surface, and ultimately advising whether the system is ready to release. Without that stewardship, UAT often degrades into informal demos that discover nothing useful until go-live.

Planning UAT: Six Key Steps

Define scope. Which business processes does this release touch? Map them back to the requirements in the SRS (System Requirements Specification). Everything in scope needs at least one UAT scenario; out-of-scope items must be explicitly excluded to prevent scope creep during the sessions.
Select participants. Choose representative actual users — not managers who know the process conceptually, but the people who perform it daily. For an online store, that means warehouse pickers, customer-service agents, and an accounts clerk, not just the IT manager. Aim for a small, focused group: 3–8 per business area.
Design test scenarios. Scenarios are end-to-end business stories, not technical test cases. Each scenario describes a realistic situation ("A customer places an order for a product that is out of stock but available on back-order") and the steps the user will take. The expected outcome maps to the acceptance criterion in the SRS.
Prepare the test environment. UAT should run in a dedicated environment seeded with realistic (but anonymised) data. Using production data risks privacy violations; using meaningless dummy data means users cannot recognise plausible results.
Brief participants. Hold a short orientation: explain what UAT is (not a performance assessment of the user), how to log a defect, and how to distinguish a genuine defect from a change request.
Schedule sessions. Block real time in users' calendars — at least two half-days for a modest system. Compress UAT sessions or run them amid full workloads and you get shallow coverage.

Entry Criteria: When Is UAT Ready to Start?

Entry criteria are the minimum conditions that must be true before UAT begins. Starting UAT with a system that fails its own internal tests wastes business users' time and destroys confidence. Typical entry criteria include:

System Integration Testing (SIT) has been completed and signed off with no open critical or high severity defects.
The UAT environment has been deployed and smoke-tested (key screens load, logins work, test data is in place).
UAT test scenarios have been reviewed and approved by the business sponsor.
Participants have been confirmed, briefed, and their calendars blocked.
A defect-tracking channel (shared spreadsheet, Jira project, or equivalent) is ready and access has been granted to all participants.

Never skip entry criteria under schedule pressure. Starting UAT on an unstable system leads to a flood of basic defects that business users must wade through to reach real business scenarios. They disengage, the timeline slips further, and confidence in the project collapses. Enforce entry criteria firmly — even if it means delaying the UAT start date.

Running UAT Sessions

A well-run UAT session follows a clear structure. Consider a logistics firm testing a new shipment-tracking portal for its customer-service team:

The analyst opens with a 10-minute briefing: purpose, logistics, and how to log an issue.
Users work through scenarios individually or in pairs. The analyst observes — silently. Jumping in to "help" with the system prevents real usability issues from surfacing.
When a user is stuck or discovers something unexpected, they note it on a defect / observation log: what they were doing, what happened, and what they expected.
A mid-session check-in (15 minutes) clears up procedural confusion without biasing the test.
A closing debrief captures overall impressions and any scenarios not completed.

The analyst collects the observation logs, triages each item as a defect (system does not meet the agreed requirement), a change request (system works as specified, but the user wants something different), or an observation (minor usability note, not a blocker). Only defects block go-live; change requests go into the backlog.

UAT process flow across three swimlanes: Analyst (blue), Business Users (green), Sponsor/PM (yellow).

Exit Criteria: When Is UAT Complete?

Exit criteria define when the UAT phase is finished — whether successfully or not. They prevent UAT from drifting on indefinitely ("just one more scenario") or closing prematurely under management pressure. Typical exit criteria include:

All planned UAT scenarios have been executed (or formally deferred with documented justification).
Zero open critical or high severity defects (defects that prevent a core business process from completing).
All open medium severity defects have an agreed fix date within a defined post-release window.
The business sponsor has reviewed the defect log and signed the UAT Sign-off Document.
Any deferred items have been formally logged as post-release change requests.

Conditional sign-off is common and acceptable. In practice, sponsors often sign off with a short list of medium-severity defects that will be fixed within two weeks of go-live. Document this explicitly — what is still open, who owns the fix, and by when. Verbal agreements evaporate; written conditional sign-off protects everyone.

Entry criteria (left) gate the start of UAT; exit criteria (right) gate the sign-off and go-live decision.

Common UAT Pitfalls

Testing the wrong people. Managers who designed the original process often test differently from the clerks who execute it. Include front-line users.
Confusing change requests with defects. A user saying "I wish this worked differently" is not the same as "the system does not meet the agreed requirement." Treat them differently — defects block release; change requests go into future iterations.
No clear sign-off authority. UAT must end with a named individual (usually the business sponsor) formally approving go-live. Without a named approver, UAT drifts indefinitely.
Too short or too rushed. Compressing UAT to a single afternoon for a complex system almost guarantees critical defects reach production. Budget adequate time from the start.

A UAT scenario template to use immediately. For each scenario write: Scenario ID, Business Process, Pre-conditions, Steps (numbered), Expected Outcome, Actual Outcome, Pass/Fail, Tester Name, Date. Even a shared spreadsheet with these columns is enough to run professional UAT on a modest project.

UAT is the moment where analysis work is judged by the people it was always meant to serve. A well-planned UAT, with clear entry and exit criteria and the right business participants, is one of the highest-value activities a systems analyst can lead — protecting the organisation from a costly failed go-live and giving the development team a definitive, trusted verdict on their work.