UAT stands for User Acceptance Testing. It's the final testing phase before software goes to production, where actual users (not QA engineers, not developers) test the software to confirm it works for their real-world needs.
That definition sounds straightforward. In practice, UAT is the phase most teams either skip entirely or execute so badly that it catches nothing. A product manager emails 8 people asking them to "test the app before Friday," nobody knows what to test, 2 people respond with "looks good to me," and the release goes out with a broken checkout flow that any real user would have found in 5 minutes.
The problem isn't that UAT is hard. The problem is that most teams treat it as a checkbox rather than a testing phase with its own scope, participants, criteria, and timeline.
Where UAT fits in the testing lifecycle
Software goes through multiple testing phases. Each one asks a different question.
Unit testing asks: "Does this function return the right output for a given input?" Developers write these. They run in milliseconds. They test code in isolation.
Integration testing asks: "Do these components work together?" The login module talks to the authentication service, which talks to the database. Do they all connect correctly?
System testing asks: "Does the whole application work?" QA engineers run test cases across the full system. They find functional bugs, UI bugs, performance issues, and security vulnerabilities.
UAT asks: "Does this software actually solve the user's problem?" Everything above tests whether the software works correctly. UAT tests whether it works usefully. The checkout flow might function perfectly (system testing passes) but require 7 taps when the user expects 3 (UAT fails).
UAT comes after all other testing is complete. If you're still finding crashes and broken buttons during UAT, you started UAT too early. Fix the bugs first. UAT isn't a bug hunt. It's a usability and fit-for-purpose validation.
UAT vs QA testing: they're not the same thing
This is the most common confusion. QA testing and UAT test different things, run by different people, with different pass/fail criteria.
QA testing is specification-driven. The spec says the login button should be blue, 44px tall, and navigate to the home screen. QA verifies those three things. If the button is blue, 44px, and navigates to the home screen, the test passes. The spec was met.
UAT is expectation-driven. The user taps the login button, lands on the home screen, and thinks "why is the first thing I see a settings panel? I expected to see my dashboard." The spec was met (home screen loads). The user's expectation was not met (they expected a dashboard, not settings). UAT catches this. QA doesn't, because QA tests what's written in the spec, not what's in the user's head.
This is why real users run UAT, not QA engineers. QA engineers are trained to verify specifications. Users bring assumptions, workflows, and expectations that no spec fully captures.
How to run UAT without wasting time
Step 1: define acceptance criteria before development starts
Acceptance criteria are the conditions that must be true for the feature to be "accepted." They should be written in plain language that business stakeholders and users understand.
Example for a food delivery checkout:
- The user can see the itemized order total (subtotal, tax, delivery fee, promo discount) before confirming
- The delivery address defaults to the user's last saved address
- Payment confirmation appears within 3 seconds of tapping "Place Order"
- The order appears in the "My Orders" list immediately after confirmation
These aren't test cases. They're success conditions. If all four are true, the feature is accepted. If any one is false, it's not.
Step 2: pick the right testers
UAT testers should be people who will actually use the software. For a B2B tool, that's employees from the customer's team. For a consumer app, that's a small group of real users (beta testers, early adopters, or internal staff who match the target audience).
Don't use developers. They'll work around bugs instead of reporting them. Don't use QA engineers. They'll test like QA engineers (spec-driven) instead of like users (expectation-driven). Don't use the product manager alone. They're too close to the decisions to see the blind spots.
5-10 testers is enough for most UAT cycles. More than 15 creates coordination overhead that slows everything down.
Step 3: give testers scenarios, not scripts
Don't hand testers a step-by-step script ("Tap field A, type 'hello,' tap button B, verify screen C appears"). That's system testing, and you already did it.
Give them scenarios that describe a goal: "You're hungry and want to order dinner. Find a restaurant near you, pick a meal, and check out using your saved card." Let the tester figure out how to accomplish the goal. The path they take reveals usability issues the script would have hidden.
For more on the difference between scenarios and scripts, see our test scenario examples.
Step 4: set a fixed timeline
UAT should have a start date, an end date, and a deadline for feedback. "Test this whenever you get a chance" produces nothing. "Test these 5 scenarios by Thursday at 5 PM and submit feedback here" produces results.
One week is a reasonable UAT window for most features. Two weeks for a major release. Less than 3 days is too rushed for testers to give thoughtful feedback.
Step 5: track feedback in one place
A shared spreadsheet, a Jira board, a Google Form, a dedicated Slack channel. Doesn't matter which one. What matters is that every piece of feedback goes to one place, not scattered across email threads, DMs, and verbal conversations in the hallway.
Each feedback item needs: what the tester tried to do, what happened, what they expected, and a screenshot or screen recording if possible.
UAT on mobile: what's different
UAT on a mobile app has constraints that web UAT doesn't.
Device variety. A UAT tester on a website uses a browser. A UAT tester on a mobile app uses THEIR phone. One tester has an iPhone 14. Another has a Samsung Galaxy A14 with "Large" font size enabled. A third has a Pixel 7 on Android 14. The same app looks and behaves differently on each device. This is useful, because it surfaces device-specific issues, but it also means UAT feedback needs to include the device model and OS version.
App distribution. On web, you send testers a URL. On mobile, you need to distribute the app build. For iOS, that means TestFlight (Apple's beta testing platform). For Android, that means a Firebase App Distribution link, a direct APK download, or a Google Play internal testing track. Getting the app on the tester's device is a step that doesn't exist on web and sometimes fails (TestFlight invites expire, APK installs are blocked by device settings).
Interruptions are part of the test. Web UAT happens in a browser tab. The tester isn't receiving phone calls, push notifications from other apps, or battery warnings while testing. Mobile UAT happens on a phone. A phone call during checkout, a low-battery popup during payment, or a notification covering the "Confirm" button are all real scenarios that mobile testers naturally encounter. This is a feature, not a bug. These interruptions expose problems that lab testing misses.
Offline and slow-network scenarios. Web users are usually on Wi-Fi. Mobile testers might be on a subway, on spotty 4G, or in an elevator. Their UAT naturally includes network conditions that are hard to simulate in QA but happen constantly in real usage.
When UAT finds nothing (and that's fine)
If UAT finds zero issues, that doesn't mean UAT was a waste. It means your earlier testing phases (unit, integration, system, regression, exploratory) did their job. UAT is a safety net. A safety net that catches nothing means the trapeze artist didn't fall. You still needed the net.
The worst outcome isn't "UAT found nothing." It's "UAT found 30 bugs." That means system testing was incomplete, and you're discovering fundamental problems at the worst possible time, days before release, with real users wasting their time on broken software. If UAT consistently finds more than 2-3 minor issues, your earlier testing phases need work.
When to skip UAT
This will sound heretical, but there are situations where formal UAT isn't worth the coordination cost.
Hotfixes for production bugs. If the app is crashing for 10% of users and you have a one-line fix, ship it. Don't wait for a UAT cycle. The production users ARE your unwilling UAT testers right now, and they're failing.
Routine maintenance releases. Dependency updates, minor copy changes, security patches. If the change doesn't affect user-facing behavior, UAT adds overhead without value. Automated regression tests cover this better and faster.
Small teams with continuous deployment. A 3-person startup shipping daily doesn't need a formal UAT phase. The founder is the user, the developer, and the tester. Formal UAT is for teams large enough that the people building the software aren't the same people using it.
UAT in specific industries
Banking (UAT meaning in banking). UAT in banking is heavily regulated. Testers must verify compliance with financial regulations (PCI DSS for payments, SOX for financial reporting). UAT sign-off is a formal document that auditors review. The stakes are higher because a bug in a banking app can move real money incorrectly.
Business/Enterprise (UAT meaning in business). UAT in enterprise software often involves multiple departments (sales, finance, operations) each testing their own workflows. A CRM change that works for the sales team might break the reporting dashboard that finance relies on. Cross-departmental UAT is slower but catches integration issues between business units.
FAQ
What does UAT stand for?
User Acceptance Testing. It's the final phase of software testing where real users validate that the software meets their needs and is ready for production release. Also called end-user testing or application testing.
What is the difference between UAT and QA?
QA testing verifies that software meets written specifications (does the button work as the spec says?). UAT verifies that software meets user expectations (does the feature solve the user's actual problem?). QA is run by testers. UAT is run by real users or business stakeholders.
Who should perform UAT?
Real users or people who closely match the target audience. For B2B software, that's employees from the customer's organization. For consumer apps, beta testers or internal staff who match the user profile. Not developers, not QA engineers.
How long should UAT take?
One week for a typical feature release. Two weeks for a major release. Less than 3 days is too rushed for meaningful feedback. UAT should have a fixed start date, end date, and a feedback deadline.
What happens if UAT fails?
The release is held. The team reviews the feedback, determines which issues are blockers (must fix before release) vs nice-to-haves (fix later), addresses the blockers, and runs UAT again on the fixed version. Shipping software that failed UAT is shipping software your users already told you doesn't work.
Is UAT manual or automated?
Mostly manual. UAT's value comes from real users bringing real expectations and real workflows to the software. Automated tests verify specifications. Humans verify usefulness. Some teams automate the setup (distributing builds, collecting feedback) but the testing itself is human-driven.
