UAT

UAT

UAT stands for user acceptance testing. It is the phase where the people who will actually use the software check that it does what they need, before it goes live. It answers whether the build solves the problem, not whether the code works.

Go back to Glossary

What does UAT stand for?

UAT stands for user acceptance testing. It is the phase where the people who will actually use the software check that it does what they need, before it goes live.

It sits after the technical testing. QA has already checked the code does what the specification says. UAT checks whether the specification was right.

What does UAT mean in business?

In business, UAT means the point where the people who asked for a system confirm it supports their work and formally accept it. That applies to software built in-house, to an agency's delivery for a client and to a vendor's ERP rollout, where acceptance is often a condition in the contract.

Outside software and business, UAT is also the abbreviation for the University of Advancing Technology in Tempe, Arizona.

Who runs UAT

Not the development team. UAT is run by the people who will use the software day to day, or by the client who commissioned it. That is the whole point. A developer testing their own work checks that it behaves as designed. A user checks whether the design was correct.

In practice that means business users, subject matter experts, sometimes a customer's own staff. They test against real tasks rather than test cases.

UAT vs QA testing

QA asks "does this work as specified?" and is run by testers against defined cases. It catches defects.

UAT asks "does this solve the problem we had?" and is run by users against real work. It catches misunderstandings, which are more expensive and usually surface later.

Software can pass every QA test and fail UAT completely, because passing QA means the team built what was written down and UAT is where you find out whether what was written down was what the business needed.

What is a UAT environment?

A UAT environment is a separate copy of the system, set up to match production as closely as possible, where users test without touching live data or the developers' unfinished work.

Most teams move a release through four environments in order: development, test (where QA runs), UAT or staging, and production. If the UAT environment has different data, settings or integrations from production, testers end up accepting something that will behave differently after go-live.

What are the types of UAT?

The ISTQB, the body that certifies software testers, lists several forms of acceptance testing. User acceptance testing is the best known of them.

  • User acceptance testing: business users check the software supports their everyday tasks.
  • Operational acceptance testing: IT operations checks backups, recovery, monitoring and maintenance before go-live.
  • Contract acceptance testing: the delivery is checked against the acceptance criteria written into a contract.
  • Regulation acceptance testing: the software is checked against the legal or regulatory rules it must meet, common in finance and healthcare.
  • Alpha and beta testing: alpha runs with internal users or invited customers at the developer's site. Beta runs with real customers in their own environment, usually before a wider release.

The UAT process

  • Define what acceptance means. Which tasks must be completable, by whom, without help. Vague criteria produce a sign-off nobody trusts.
  • Recruit real users. People who do the job, not people who understand the software.
  • Give them tasks, not scripts. "Process a refund for an order placed last month" tells you more than a numbered click sequence.
  • Capture what they hit, in context. Screenshot, browser, what they were doing. A report that says "it didn't work" costs a day to reproduce.
  • Decide and sign off. Which issues block release and which are logged for later.

Where UAT usually goes wrong

The most common failure is the report format. Testers who are not technical describe what happened in their own words, and the development team cannot reproduce it. Half the UAT cycle then goes on clarifying rather than fixing.

The second is treating sign-off as the end. UAT catches what a small group notices in a short window under artificial conditions. Real users find different things, at volume, once the software is doing actual work. Teams that close the feedback channel at go-live lose exactly the information that was hardest to get.

The better pattern is to keep the same channel open after release, so acceptance testing becomes the first round of continuous feedback rather than a one-off gate.

UAT for enterprise product teams

At enterprise scale, the hard part of UAT is proving the release was accepted. A change to a billing system might be tested by finance teams in three regions, by support and by a client's own staff, each against their own tasks.

Two records decide the go/no-go meeting. Each issue needs to show who raised it, on which step and in which environment, so the discussion is about evidence instead of recollection. The sign-off needs its own record too: which acceptance criteria passed, which issues were deferred and who agreed. In regulated industries, that record is often the first thing an auditor asks for.

How Usersnap supports UAT

Testers report without leaving the software. They point at what is wrong and annotate a screenshot, and Usersnap attaches the browser, operating system and screen size automatically, so the report arrives reproducible instead of described. Screen recordings cover anything a screenshot cannot show.

Reports land in one place and can be pushed to Jira, Linear or Azure DevOps so they enter the workflow the team already uses. The same widget stays in place after go-live, which is what turns a testing round into an ongoing channel.

UAT FAQ

What does UAT stand for in software?

User acceptance testing. The final testing phase, run by the people who will use the software, checking it meets their needs before release.

What does UAT stand for in project management?

The same thing. In project management it is usually the gate before go-live, where the client or business owner formally accepts the delivery.

What is the difference between UAT and QA?

QA verifies the software matches the specification. UAT verifies the specification matched the need. QA finds defects, UAT finds misunderstandings.

Who performs UAT?

End users, business stakeholders or the client. Not the developers who built it, and usually not the QA team who tested it.

Why do people say "UAT testing"?

Strictly, "UAT testing" repeats itself, since the T already means testing. People say it anyway because it makes the acronym clear to listeners who don't know it, and in most teams both forms mean the same thing.

Related terms

See how teams collect UAT reports with the browser and device details already attached.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.