You’ve gotten through all the features on your initial product roadmap and are ready to release—but wait: There’s still one more step.

The last order of business before releasing a product is getting client sign-off that the requirements were met. User Acceptance Testing (UAT) gives end users and the product owner the chance to review the product and make sure that it meets their business needs. UAT isn’t about finding bugs, though it may find a few. It focuses at a much higher level and concerns itself with whether the product delivers the functionality that was needed.

Beta testing is an informal process that hands the almost-ready product to a set of users and asks for feedback, but UAT needs to be managed much more formally. It requires a test plan and users assigned to work through scenarios that simulate the real usage of the product. This way users and management can determine if the application truly supports the use cases and if the user interface is easy to work with.

Because UAT is the last step before deploying an application, it’s critical to make sure it happens smoothly so issues can be resolved before release. The product manager or someone else on the development team should coordinate the testing process to ensure that all activities are moving along according to schedule.

Prepare for UAT

Most of the preparation for UAT is done by the development team, not the users. Make sure you have:

• A tested application. The QA test should have completed successfully before the application is given to end users. If there are basic bugs, users won’t be able to perform the functional testing that’s key now.
• A test plan. UAT needs to comprehensively test the application against its requirements. There should be a formal test plan that documents the steps to be performed for each test case and the expected results. In an ideal world, the business would write the UAT, as they have the best understanding of what the application should do, but in most cases, they won’t be able to do this. Either the PM or the QA team should produce a test plan, using the requirements and use cases as a guide.
• An environment to test in. UAT should be performed in a separate environment from QA and development in order to ensure there is no conflict caused by having multiple activities going on at the same time. Ideally the UAT environment will mirror the production environment in terms of capacity so the users experience the same performance they can expect in production. Make sure the environment is ready before turning it over to the users. When users aren’t able to log in because their credentials weren’t set up or the application won’t start up because it wasn’t installed properly, they get frustrated and approach testing with a negative attitude.
• Users to perform the test. You need end users with good knowledge of the application’s functionality to execute the test cases, so business management needs to commit to pulling their experts off business functions for the duration of the test and give them enough time to dedicate to the test process. You also need enough users to ensure that tests that require multiple users working in the application simultaneously can be executed.
• A way to track test results. Provide the users a straightforward process for collecting the results of their test cases. This can be as simple as listing tests in a spreadsheet for the users to check off as they are done.

Execute the Test

For the most part, executing the test is the users’ responsibility. Nevertheless, the development team is a key participant in the testing process. You should:

• Have developers on standby. Things can go wrong during UAT. There should be developers available to fix any environmental problems interfering with the test. Any showstopper bugs need to be fixed immediately. Sometimes you may want to have a developer on site with the testers to observe any problems they have with the interface, as users aren’t always explicit with their feedback.

Assess the Test Results

In a perfect world, the application would be bug-free and management would sign off on the product without any debate. Unfortunately, that rarely happens, and you need a process to evaluate the test and respond to the issues it found:

• Follow up with users to get their opinions on the product. Statistics of how many tests were executed and how many passed don’t capture the complete user experience with the product. Get users’ opinions about how easy the product was to work with, what aspects frustrated them, what their favorite feature was, and what they’d like to see in future releases.
• Document the test results. Make sure everyone agrees on how well the test went by creating a report that details the tests that were executed and how many passed or failed. Include the qualitative user opinions as well.
• Prioritize the issues that were found. Reported problems need to be evaluated as bugs, misunderstandings of stated requirements, or new requirements. These should be prioritized through discussion with the users to determine whether they need to be addressed before releasing the product or if they can be resolved in a follow-on release.

Move On to More Development

Once you have sign off, you can move on to packaging the product for release and working on the next version. Make things easier by doing UAT more often and earlier in the development process—you can do a small UAT at the end of every few sprints instead of waiting to test with users when you’re thinking about release. That helps reduce the biggest problem with UAT: the later in the development process bugs are found, the more costly they are to fix, and UAT is usually the last step.

The other thing to remember is that a smooth UAT depends on a smooth development process. The most important preparation you can do for UAT starts way back during requirements. Get everyone aligned on the product’s requirements at the start and you’re much more likely to have everyone in agreement about them at the end, too.