Getting Down to Basics with User Acceptance Testing (UAT)

By Nilesh Patel, KMS Technology


Towards the end of development, every piece of software should be subjected to a final phase of testing. It doesn’t matter if you call it user acceptance testing, end user testing, or beta testing. The aim is the same: to ensure that the application meets the intended business functions for end users in real-world conditions. User acceptance testing (UAT) enables developers to make a final round of adjustments before the software is released. It’s the last chance to raise any lingering issues and confirm that the software actually does what it’s intended to do. This requires a change of gear from the test team.

A Fresh Perspective on User Acceptance Testing

To simplify, good testers are masters of breaking things. They can look at an application, consider how it works, and immediately imagine a number of ways that you might trip it up. Testers often focus on negative scenarios to unearth defects. They bring their functional testing experience and technical knowledge to bear.

End users are different. They’re focused on positive scenarios because they try to achieve goals, which are typically aligned with the business functions the application was created to fulfill. In other words, they don’t go out of their way to break apps. They also have little understanding of what’s going on behind the scenes. They don’t know what database is being accessed or what technology is being used, and they don’t care. They just want things to work as expected.

Know Your User

Testers have no problem creating detailed functional tests based on a set of requirements, but with UAT the test cases have to be simpler. They should be drawn from use cases and they can’t afford to be too specific because there’s a lot of value in seeing how end users go about completing a task. Do they make assumptions and take wrong turns? Are there problems that the developers and testers can’t see because they’re so close to the application and so are familiar with it?

To create a good set of end user tests, it’s important to understand who the end users are. What does the typical user of this application look like? What age are they? What gender? Depending on the application in question, there could be other important demographics. This information is obviously necessary for recruiting beta testers, but it also helps to create solid use cases.

A broad range is often desirable and so it may be necessary to design test cases for different groups of end users. If they lack a lot of business domain knowledge, they might require more support and simpler test cases.

Understand the Business Reasons for User Acceptance Testing

Sometimes, testers might create use cases, but usually they’ll be provided by business analysts. It’s vital that testers are able to discuss the UAT with the business team and build a clear picture of what kind of feedback they’re looking for. Is the focus on uncovering defects, finding usability problems, or a mixture of both?

This will really help testers to create the right kinds of workflows and checklists for the beta testers to complete. There’s also a chance that the business team will want a particular focus on a certain set of features, or that something will crop up in the first round of UAT that they feel requires more investigation, and the test cases will have to be amended to accommodate that.

Real-world Conditions

To get as clear a picture as possible from the UAT, it’s important to use real-world data, not test data. Ideally, you’ll test in the production environment. The aim is to mimic the final real-world application conditions as closely as possible. If you use a test application or a separate test server, you’re not necessarily going to get the full picture.

Find ways to emulate your expected user numbers and consider potential complications. End users may encounter issues with software conflicts or browser plug-ins. Beta testing and real-world conditions really widen the net for catching defects.

When the UAT begins, testers will have to work to interpret and categorize the results coming in. They’ll need to differentiate between genuine defects and feedback issues on usability. Any problems with the test cases should become clear pretty quickly, and they can be tweaked and refocused through discussion with the business team.

The closer that UAT can get to emulating the final real-world scenario for the application in terms of data, environment, and users, the more confident everyone can be about signing off and pushing it live.

About the Author

Nilesh Patel is QA Manager for KMS Technology, ( a provider of IT services across the software development lifecycle with offices in Atlanta and Ho Chi Minh City. He was previously at LexisNexis doing independent software testing. Contact him at [email protected].

More by Author

Must Read