User acceptance testing (UAT) is the final phase of testing of a large application development project that you (the recipient whom the work is being done for) do “in-house” to make sure that your new software application, (or a major enhancement to an existing application), solves the problems that you set out to solve for your users.
It is often overlooked and not given the attention it deserves. This is partially due to the fact that it comes at project end and often projects are rushed to launch. However, it is also often a part of the project that is misunderstood. UAT is essential for launch success, and demystifying both the need and approach is important.
Do We Really Need to Do UAT?
Yes.
You should do it because if you left something out that should have been included, or you have a workflow that doesn’t really match the real-world business workflow, you’ll want to find that out for yourself rather than have your users and customers tell you after you’ve released your application.
Our customers often ask why UAT is needed after all the functional testing that’s been done by the development team during the implementation phase. However, functional tests only confirm that the features work as designed. User acceptance testing goes well beyond this, as it seeks to answer the question, “Will users accept the solution given the problems that it’s intended to solve?”
Who Should Perform UAT?
You don’t want to leave this critical step to the team that designed and built the solution, because their viewpoint is one of knowing how the application is intended to work. In addition, they often lack the subject matter expertise to represent your real-world users.
Instead, you want people who are knowledgeable about the problems that the solution is designed to solve, and have a depth of experience with those problems that they can readily bring real-world scenarios into their testing. In other words, you need testers who can get inside the minds of your target users. If you had a subject matter expert who was consulted during the discovery and design phase, you should have them on your user acceptance testing team. However, you also want at least one tester who wasn’t consulted or didn’t work closely with the design team, because they will bring a perspective that is uninfluenced by the design decisions.
Do You Need to Create a Formal Test Plan for UAT?
Requiring a test plan with formal test cases for UAT can be an impediment to successfully completing this phase, because testers will often fall into simply re-iterating the functional tests that have already been completed as part of development. However, if you simply “wing-it” without any prior thought and planning, you’re likely to fail to get value from your efforts. For this reason, we recommend that you create a test plan that incorporates the following:
- Outline the specific tasks you expect your users to be able to accomplish with the application. If you are following an agile development process, your written “user stories” should provide a clear starting point for this. Take note that your tasks should be agnostic to the actual application, so that you keep the focus on the business problem rather than on merely following the steps the application expects you to follow.
- For each of the tasks, have your testers outline the real-world scenarios they expect to encounter when attempting to complete them. Each of these task/scenario combinations represents a single test case.
- Tell your testers to be prepared to add scenarios (and hence test cases) as they perform the testing, as they’ll inevitably think of new scenarios as they use the application to complete the tasks. It sometimes happens that these new test cases arise when the tester realizes that there’s an important scenario that they can’t complete with the application. The reason it’s important to still capture this as a test case is that you’ll want to come back to it after you’ve attempted to resolve the issue with a change to the application.
UAT is important because it provides you with the best opportunity to catch and correct design missteps or omissions before your users see them. To successfully complete this critical phase, you need to engage testers who have subject matter expertise and who are not intimately familiar with the application design and who can approach their testing from the “business problem” perspective. You’ll get more benefit from UAT if you plan your testing around the real-world tasks and scenarios that the application is designed to handle, rather than simply turning testers loose on the application without direction.