Plutora Blog - Software Development, Test Environment Management, Test management
User Acceptance Testing (UAT): What It Is and How to Adopt ItReading time 13 minutes
Have you heard of “user acceptance testing?” I’m afraid that for many of you reading this post, the answer will likely be “No.” Unlike other more famous types of testing, UAT is not as a frequent topic of conversation as it should be. Even if you are vaguely familiar with the term itself, do you know what user acceptance testing is, what is used for, and why your organization should care about it?
Again, the answer to the questions above is most likely, “No.” This post is our attempt at remedying this situation. We’ll begin by explaining what “user acceptance testing” means. Not only will we define the term, but we’re going beyond that. You’ll learn about the need for user acceptance testing, understanding why other types of testing can’t fulfill it. We’ll also talk about the people involved in actually performing these types of tests, as well as the correct timeframe to do so.
Then, we’ll get to the “how” part of the post, walking you through a list of steps you can follow to get your organization up and running with UAT in no time. We then part ways with some final advice on how to make the whole process more efficient.
Let’s get started.
Defining User Acceptance Testing
Let’s begin our journey towards understanding user acceptance testing and the role it plays—or should play—in the software development process. But it’s impossible to understand something without having a clue on what the term itself means, so that’s clearly our first step.
User Acceptance Testing—What Does That Mean?
Whenever I’m tasked with defining a term, I usually take one of two approaches. I might employ the “divide and conquer” strategy, breaking the term down into its constituent parts, defining each one individually, and then joining their definitions together to try and create a cohesive definition for the whole. Or I just search for existing definitions, and then I distill and simplify them. Today I’m going with the latter approach.
First, let’s see what Techopedia has to say about the topic:
User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications.
It’s a good definition, but let’s not stop there. Wikipedia offers its own user acceptance testing definition:
User acceptance testing (UAT) consists of a process of verifying that a solution works for the user.
This definition is spot on. It’s as straightforward as it can get. I’d only make a little tweak, replacing the generic “solution” for a more specific term. We’re talking about software development here. So, based on the two definitions you’ve just read, here comes my own UAT definition:
User acceptance testing (UAT) is the type of software testing that verifies that a given application works for the user.
So, is that it? Does user acceptance consist of the user giving their proverbial thumbs-up to the application? We could say that, yes, that’s the essence of it. Of course, there are more pieces to that puzzle, but the crucial thing to remember about UAT is the importance and centrality of the user.
It’s All About The User
When it comes to this type of testing, the user is the key element, as its name makes clear. The users are the people who’ll use the application, if not daily, at least frequently. So, it’s vital to make users part of the whole quality strategy in the software development process.
That’s where UAT comes in handy. This type of testing, more than any other, puts the users’ needs at the center of the discussion. These are some of the questions that it attempts to answer:
- Are the users able to use the application?
- Does the application behave in expected ways?
- Does the application solve the users’ problem?
At this point, you might be thinking something like this:
“This whole UAT thing sounds like it’s important, kind of, but do we actually need it? I mean, we already have lots of unit tests…aren’t those sufficient?”
That is actually a good question to bring to the table. The short answer is “No.” The slightly longer answer is in the next section.
Other Types of Testing Are Not Enough
You might be wondering if user acceptance testing is really needed. After all, we have a plethora of types of testing—manual, and automated. The other type of testing that pops into peoples’ heads first is, most likely, unit testing. Integration testing is a strong contender for the second place, as is functional testing. I’m sure you can think of many more types of testing. After exhausting your memory/knowledge, you could always take a look at Wikipedia to learn about more types of testing than you knew were possible.
So, there are plenty of types of testing. But, do we really need one more? Aren’t these other types of testing enough?
The answers to the questions above are “Yes” and “No,” respectively.
There are many different types of tests because there are many different testing needs. You usually can’t replace one type with another. You can’t use integration tests instead of unit tests, because they serve different purposes. Sure, maybe your scenario favors one type of test more than the others. Perhaps unit tests don’t make sense for your application. I personally would find that highly unlikely, but it might be the case. But if your scenario really calls for unit tests, then there’s no amount of other types of test that can make up for it.
UAT scratches an itch that no other type of testing does. And that’s an itch that you need scratching, whether you know it or not.
Why Should You Adopt User Acceptance Testing?
Before we get into the practical steps you’ll use to get your organization up and running with UAT, we need to be on the same page regarding your need to do so. And I do believe that virtually everyone reading this post can adopt UAT and would benefit greatly by doing so.
A few sections ago, we talked about how there are many types of software testing. We said that you couldn’t swap one type for another, as each one serves a unique purpose. What we haven’t mentioned is that not everyone needs to employ all types of testing, all the time. Sometimes that’s not even possible (e.g., performing GUI testing on a console application.)
That being said, we do believe that UAT is one of those few essential types of tests that virtually everyone should perform. At the end of the day, your mileage may still vary, but it’s likely that your organization would benefit from adopting user acceptance testing, regardless of your company’s size, the number of people on your team, the tech stack you use, the platform your app is supposed to run on, or pretty much any other factor. And why is that?
UAT consists, in practice, of people from the target audience using the application. The defects they find are then reported and fixed. This scenario is what most closely resembles “the real world.” The process allows users to “get their hands dirty” with the application. They can see if things work as intended.
The user acceptance testing process is often the final verification step before the release of the application. Since UAT simulates real-world conditions, when the application works as intended during the testing process, it’s safe to assume that it will also behave properly in production.
Who Should Perform User Acceptance Testing?
You might think that this is a useless question with an obvious answer. Isn’t the user responsible for performing UAT?
Well, yes and no.
These tests should be performed by a subject-expert matter—a.k.a. “domain expert,” to use domain-driven design jargon. Ideally, these experts should be real end-users of the software in question. For practical reasons, not always is that possible. In that case, the team should have a person that acts on behalf of the user/client and has the authority to approve or disapprove features. If you’re thinking about the customer representative role in extreme programming, you’re not too far off.
In short, who performs UAT? Ideally, end users, when possible; otherwise, expert domains that can act on behalf of the clients.
The Right Time to Start Performing UAT
Up until now, we’ve covered several aspects of user acceptance testing. You now know what it means, what it’s used for, and how it can’t be replaced with other types of testing. The previous section answered the question “who performs user acceptance testing?” whose answer might not be as apparent as it seems. The section before that listed the reasons why your organization, regardless of team-size, target platform, or any other criteria, should adopt UAT.
Since we’ve covered the “what,” “why,” and “by whom,” let’s turn to the next question: “when?” As in, “when is the correct time, during the software development lifecycle, to perform user acceptance testing?”
There are some types of testing you can perform at any time during development. UAT isn’t one of those. Usually, you’re not able to execute UAT until the software reaches a reasonable level of completeness, at least from a feature point of view. In fact, there are some prerequisites that need to be met before user acceptance testing is able to take place. Of course, YMMV. Not all of the conditions will be relevant for all scenarios. Let’s talk through some of them.
First of all, you need business requirements in place. In other words, you must have the specs written down for the piece of software you intend to test. These specifications, or business requirements, will guide the development of the test cases for UAT (more on that later.)
Another important—though somewhat obvious—requirement is that the code should be complete. It wouldn’t make any sense to test an incomplete feature.
The other types of tests that your organization employs—for instance, unit and integration testing—should also be completed. It wouldn’t make sense to put time and effort into a higher-level type of testing if the lower-level types of testing, more concerned with technical details, aren’t finished.
Speaking of other types of testing, regression testing should be successfully performed. That is, no significant defects should be found. If there are defects, you should fix them ASAP and repeat the testing session.
Finally, the environment for the user acceptance testing process must be ready. That means that all of the infrastructure needed—software and hardware—should be in place.
Getting Started With UAT: 5 Easy-To-Follow Steps
Now it’s time to give you some general guidelines on how you can implement user acceptance testing in your organization. We’re doing that by walking you through the following five steps.
1. Have Your Definition of Done in Place
First of all, you need to define and write the down the criteria that you’ll use to decide that a given piece of software is complete. This type of checklist is often called “Definition of Done” (DoD), which is a term popularized by scrum. It’s crucial for the team that all members agree on what “done” means.
2. Have Requirements for Each Feature in Place
You should write the requirements for each feature that you intend to test. Modern software shops will most likely collect those in the form of user stories. The exact artifacts and medium for these requirements might vary. You could use post-it notes on a whiteboard or a sophisticated project management application. What matters is that you capture the requirements for each of the intended features for the application.
3. Create the Test Cases
Based on both the Definition of Done and the requirements for the functionality, it’s time to create the test cases for each feature. A test case is, in short, a sequence of steps, each with their expected results. Each test case covers one usage scenario of the application. It usually consists of a series of actions that the user—or its representative—can perform and then check whether the program behaved as it was supposed to.
4. Perform the Tests
With the test cases in place, the next step is actually to perform the tests. For each one of the test cases, the tester will execute the specified actions, recording the results. If the user finds a defect, it has to be fixed ASAP. Then, the user performs the test again.
5. Get The Sign-Off From The Client
Finally, it’s time for the aforementioned proverbial thumbs-up. When everything is working as intended, the user/client/customer representative will give their sign-off, indicating that the application meets their needs and it’s ready for use.
How to Make the User Acceptance Process More Efficient
Once you have your UAT up and running, the next logical step is to up your game. There could be many different ways to improve your user acceptance testing process. Here, we’ll focus on efficiency.
Suppose you followed the steps outlined in the previous section and things worked! Your company succeeded in adopting user acceptance testing. Cool! Problem is, it didn’t take too long for the management of the process to become a burden.
Manual tracking and management of a test environment doesn’t scale. It might work when you have small teams and few environments. But as soon as your organization starts to grow, the amount of work needed to track it all grows as well. Sooner than later, you’ll be asking yourself if all that effort is worth the trouble.
There is only so much you can do with spreadsheets and Access databases. To relieve the burden of managing the complexity of many testing environments, you need a tool like Plutora. By employing Plutora’s Test Environment Management tool, you can quickly and easily manage multiple test environments, centralizing bookings, solving conflicts, and tracking system dependencies. There’s much more you could do with Plutora. Go to the website, request your demo, and give it a try.
You Can’t Afford Not to Employ User Acceptance Testing
Modern software development features plenty of types of testing. Every one of them is important since they serve different purposes. Few of them are essential for all scenarios, though.
We believe user acceptance testing is one of those few. It fulfills a need that no other types of testing do. Even so, it’s often overshadowed by other, more famous, types of testing. This post was our take at solving this problem. I hope we can use the content presented here to start your own UAT process and start repaying the benefits right away.