How-To Guides

What Is User Acceptance Testing (UAT) And How to Do It Right

Last updated:
April 19, 2022

There is a surprisingly high amount of literature on user acceptance testing out there.

Do you want to become an expert in UAT, in its jargon and processes? This guide is not for you.

If you just want to make your website or web application better, and believe UAT can help you achieve this—read on.

In this guide, you will learn:

  • What user acceptance testing actually is;
  • How to conduct UAT from A to Z.

There’s a lot of ground to cover, so let’s dive right in.

What is User Acceptance Testing?

User acceptance testing is a phase of software development where your ideal customers test your app in a production-like environment.

It’s the phase after your internal QA testing and before you push your site to everyone.

The goal of UAT is to figure out this:

Are people using our app the way we expect them to?

That’s it.

Because people tend to use terms around the topic interchangeably, let’s clarify a couple more things.

Internal QA vs UAT

Both QA and UAT involve heavy levels of testing. Plus, they are performed at the same stage of the software development life cycle.

So, it’s not uncommon to confuse the two. After all, UAT is a form of quality assurance, right?

There are several key differences between QA and UAT.

Most importantly:

  • QA is carried out by your product team. However, it is the end-user (or product owner) who executes UAT.
  • QA focuses on fixing and improving technical issues. The main goal of UAT is to ensure the product or feature you’re building works in real-world scenarios.

Take a standard sign-up flow as an example:

QA testing questions:

  • Are all input fields and buttons usable?
  • Does the email verification function run properly?
  • Are there any unexpected bugs at any point in the workflow?

UAT questions:

  • Are testers filling out the correct information?
  • Do they understand what’s happening when being redirected to the login page?
  • Are they opening their email and going through the verification steps?

Alpha testing VS beta testing

There are two phases to user acceptance testing: alpha testing and beta testing.

Let’s have a look at what each stage entails.

In alpha testing:

  • The tester is the product owner. Depending on how big the project is, you might bring in friends and family or other business people for testing.
  • Critical issues still exist. Workflows might be broken or unclear. Bugs overlooked by developers can still occur—these are immediately reported and worked on.
  • It takes time. At the very least 4 weeks.
  • Your main goal is to prepare for beta testing. Alpha testing eliminates potential security issues. It also ensures people can use your product without significant hiccups.

In beta testing:

  • A fraction of your current users become your testers (on a staging environment). These should represent your average customer.
  • It’s a short phase. You’ve already dealt with the most critical issues: beta testing is more of a monitoring stage.
  • Your main goal is to experience your app from the customer’s point of view. As well as receive feedback on your software as a whole or on the feature you’ve developed.

Why do you need UAT?

If we haven’t convinced you that your app needs UAT to be a better product, let’s look at some more advantages.

First, there’s the obvious.

Your testers will tell you what’s wrong with your app before you release it to the public.

Sure: developers will catch most issues when they do their code review. Technically speaking, the app might be flawless.

But because they are so stuck in the details, they can forget the bigger picture.

A first-time user is a fresh point of view. If anything about your app is confusing, or they can't figure it out at a glance—they’ll tell you.

Some more advantages of UAT:

  • A production-like environment without the drawbacks of live testing. In a proper UAT setting, you copy your production database. You can then observe real use cases from real users rather than “expected usage” in a local environment.
  • Dozens of testers. More feedback and a higher chance to catch the more obscure bugs you’d never see on a smaller scale.
  • Fix issues upstream. Major malfunctions, confusing UI, critical security errors—you don’t want this to happen after releasing your app to the public. An app that passes the user acceptance stage is an app ready for production.
  • No-bias testing & feedback. For the most part, UAT exposes uninvolved, new users who:
    a) Do not have a pre-determined idea of how they’re supposed to use the app.
    b) Have no business investment in your software, therefore impartial and blunt in their feedback.

How to Conduct UAT [Case Study]

In this section, we want to give you a hands-on example of how user acceptance testing actually goes down in a real-life setting.

Here’s how we handled UAT for our newest feature, domain join.

1. Install a way to collect feedback

We’ve found it easiest to install a widget on our staging site.

This way, testers report bugs and send feedback as they go—without constantly alt-tabbing to email or PM tool.

We try to include as many external eyes as possible.

In alpha testing, this means our CEO and the rest of the team. They know what the new feature does, but they haven’t operated this version of our app yet.

We set up all this in our bug reporting tool,

Every piece of feedback we receive will now arrive in our project management tool (Shortcut).

This makes it easy for our developers to review, discuss, and work on bugs directly within Shortcut.

Let’s see what this looks like from the tester and developer's perspectives.

2. Collect feedback—the right way

Quality reporting is tedious.

For every bug or usability issue, you have to:

  1. Open screenshot tool, capture bug.
  2. Open software to annotate screenshots, add a few comments.
  3. Log into project management tool.
  4. Create a new issue.
  5. Document the bug.
  6. Add technical information.
  7. Attach screenshot.
  8. ...etc.

Sure: for a seasoned QA expert, this is a walk in the park.

But this is a UAT guide. And when you do UAT, you are bound to involve non-technical, novice QA testers.

This affects the quality of your tests.

The good news is that it doesn’t have to be this way.

When we do UAT, we use to automate as much as possible. Screenshots, annotations, console logs, events, OS info, and all the technical stuff gets sent to our PM tool.

For the tester, life is much easier, too:

  1. Go to staging, find a bug.
  2. Create a report and input details.
  3. Click on “Create issue”—done!

On the developer end, things are just as simple.

We’ll take Trello as an example here, but works with the most popular bug tracking tools.

When your reporters click on “Create issue”, a new issue pops up in your “Incoming” column.

When you click on an issue card, you’ll have access to the following:

  1. Description. Manually inputted by the reporter;
  2. Reporter name, source URL, console & FullStory logs, environment info. This is automatically captured by;
  3. Attached screenshot. With annotations, if any.

One added benefit of using for user acceptance testing is that you can always get in touch with the tester, even if they’re not part of your organization:

Imagine the chaos if 500 beta testers were to report issues via email.

Instead, having easy access to the tester’s insights—case by case, bug by bug—speeds up the feedback cycle and saves a ton of headaches.

Wrapping up...

User acceptance testing is about understanding how your customers use your app or website.

And to successfully conduct UAT, you need to make sure that you’re collecting that information in the best possible way.

In other words, have a system.

The resources and ideas shared in this post should be the stepping stones towards building that system—and plenty to help you put together your next UAT session.

Continue reading

Speed up website testing and collect client feedback!

Start free trial
Free 15-day trial  •  No credit card required •  Cancel anytime