What is User Acceptance Testing? An In-Depth Guide

User Acceptance Testing (UAT) is a type of acceptance testing performed by the end-user to confirm changes to the system have met the requirements or requests supplied by the user. There are several types of acceptance testing, which is the final step in the four levels of testing. However, acceptance testing and user acceptance testing are often used interchangeably.

User Acceptance Testing Explained

When a customer requests a new feature, it enters the SDLC. Once developed and added to the system, the new feature will typically go through the four levels of testing: unit testing – performed by developers, integration testing and system testing – performed by someone on the QA team, and finally, acceptance testing – performed by either a stakeholder, someone who has requested the new feature, someone who will use the new feature, or someone who represents one of the users.

UAT Testing Examples

To make the topic clearer, let’s use some examples. Imagine working on an e-commerce project for a brick-and-mortar clothing store. The website carries advertisements sponsored by local third-party restaurants. One of the restaurants has requested a new feature that offers shoppers a promo code when they view the restaurant’s site through the advertisement on your site. In this scenario, once the feature has been developed and tested by your team, someone from the restaurant would perform UAT to ensure the new feature satisfies their request.

Another example with the same e-commerce site has customers reporting that when they visit the site and search for an item, the website returns them to the homepage. Once this bug has reached development, a fix has been implemented and tested. Once more, someone who represents the customer, typically someone from the Product team, would perform UAT to confirm the fix had satisfactorily resolved the issue.

From these two examples, you may be wondering why QA is needed at all if the feature or bug fix is tested by the user. QA is necessary because the second and third testing levels (integration and system testing) are a tester’s responsibility. Testers understand the system better as a whole, so they can prevent issues from arising when testing for multiple situations.

Consider our e-commerce example again. Imagine a tester verifies that the new feature works as expected for the restaurant that requested the change during system testing. However, when the tester attempts to view a different restaurant’s site, an error occurs. If the code had bypassed QA and gone from development to UAT, the feature would have passed UAT testing and made it to production, causing unnecessary issues for the other advertisers.  

How to Perform User Acceptance Testing

Now we understand what UAT is and the importance of all four levels of testing, let’s describe the process of performing UAT.

Prerequisites

Before beginning UAT, several items are needed, most notably requirements and acceptance criteria. A user story or bug should have defined requirements or use cases ahead of development. They must document the requirements for the requested change from the user’s point of view to be sure the change will satisfy the user’s need. Vague or incomplete requirements will result in a waste of developer, tester, and user time. 

After developing the code and completing the initial testing phases, the requested change is ready for user testing. While users are the ones who perform UAT, testers are still very much involved in the process. It’s the tester’s responsibility to make sure whoever performs UAT has everything they need to complete the tests, which can include:

• Ensuring the test environment is as similar to the production environment as possible.
• Equipping the test environment with necessary test data. Data can include test accounts, admin accounts, test APIs, test payment cards, etc.
• The user has access to the test environment, including the database, if necessary.
• Any login information the user may need.
• Ensuring test cases or user stories are written in a way that enables the user to test independently.

User Acceptance Test Planning

Typically, the user will have testing scenarios in mind since they requested the change, and having acceptance criteria here will help. However, collaborating with testers may help as they can offer additional test cases because they should be more familiar with the system at this stage. Test planning for UAT should include how user feedback will be recorded, and if the user finds a bug, how will it be documented?

UAT Execution

Once the user is ready to begin testing, they may perform this action solo or they might require a start session with the tester. In an ideal situation, the user will test the item and find that everything works as expected before the item then moves toward a release. However, if a user finds an issue, reporting is needed so the item can return to the development and testing workflows. Often, the tester is responsible for performing the tests while the user observes. It may not be practical to give a user access to a database they don’t know how to use. Instead, the tester can perform the actions and show the user that it functions correctly on the front end and the back end.

Test Closure

Once UAT has concluded, the tester may have lingering responsibilities. For example, if there are known issues with feasible workarounds, the tester may need to relay the information to the support team. They might also be responsible for cleaning up test data or removing any access granted to the user during user acceptance testing. Also, they should ensure that reporting metrics are available if needed.

Challenges

The most common challenge with user testing is when the code doesn’t meet users’ expectations. This is often due to poorly written requirements. Ideally, when an issue or story is created, they contain specific information including acceptance criteria. However, this is often not the case. Unfortunately, code can be written, pass unit, integration, and system testing only to fail UAT because there was a miscommunication in requirements. Therefore, preparations should clearly define requirements and acceptance criteria ahead of development. Even so, a tester should never hesitate to ask for clarity or more information on the requirements at any point during the SDLC.

Another challenge with UAT can occur when the user discovers valid issues concerning the changes. A tester might find this situation embarrassing after changes have passed all other testing stages to be found by the user, but they shouldn’t. One of the seven testing principles declares that exhaustive testing is not possible. Quality is everyone’s responsibility. A tester should appreciate that the user found the issue when this situation occurs, which can now be remediated.

Another challenge is when the user ignores performing UAT. It can be frustrating when receiving a request presented as urgent disrupts the normal development and testing processes and then sits idle in the UAT queue. Prioritizing requests, especially ones that are ‘urgent,’ is an unenviable art that is often unmastered. Testers have the authority to politely decline the urgency of any feature when the requirements lack specificity. In other words, use good judgment when inquiring, “your last five ‘urgent’ requests haven’t been released to production because you have failed to perform UAT. Are you certain this new feature is urgent?”

Conclusion

User acceptance testing is the final level of testing before the code reaches the production environment. It is a way for the end-user to verify the changes and satisfy their request. QA is still involved with UAT and may need to provide the user with assistance. There are many challenges involved, so testers must remain insistent on having stories written with completeness, especially regarding acceptance criteria.