As projects run long and budgets get tight, the first thing that gets squeezed is testing. Even with the best of intentions, the planning, design, and development phases often go longer than expected. In order to meet that precious target rollout date, testing can get rushed. However, it is really important that testing is done properly, and this requires planning. Even under pressure, it is really important that you don’t begin UAT until…

You are absolutely sure that the development team has completed ALL of their own testing first

If the development team has not completed all of their development and signed off on their own testing, it makes no sense to have the business stakeholders involved, with hands on the keys. The bugs that the development team would have caught in their own testing will make the business users lose confidence in the system, cause frustration, and create more defects. I know that you are on a tight deadline. I know that your business users are eager to get their hands on the keys. But if the system isn’t ready to be tested by the business, do NOT let them near it.

You have frozen the scope of each phase and given the test team time to create the test scripts

A moving target is much harder to hit than a stationary one. This goes as much for test planning as it does for archery or skeet shooting. If this is a phased rollout, it’s critical that you define the scope of each phase early using your preferred prioritization technique – we recommend using a Business Objectives Model and KPIs to determine which features of your project will return the most value, and roll those out first. However you prioritize the features that go in to each phase, though, you will make the test team’s life a whole lot easier by having that conversation early, deciding what needs to be tested and when, and then sticking to that plan.

You know that the people you need to test will be available, they understand what is being asked of them, and they are comfortable with the approach

Your business users should be the main focus of UAT. Make sure that you can work around their busy schedules, communicate what the demand on their time will be, and why this process is important to them. Hopefully this will make it clear to them that this is their chance to ensure that the product works as expected. “Successful” UAT doesn’t mean that you have a few business users glance at a few screens and click some buttons just to check off the box. It really means that the business is comfortable that the system will deliver the functionality they need to do their jobs. The only way to make sure that that’s actually true is to get them to devote time to using the system in the test environment, executing the test scripts, and thinking about their business processes.

You have a process in place for identifying, reporting, prioritizing, and resolving defects

Inevitably, there will be defects. UAT is supposed to uncover defects that matter to the business, ones which the developers might not have noticed. Developers are great at developing, but the business users know what their system needs to be able to do and how it should behave. It is important to train the business testers on what a defect is and how to report them so that you get actionable defect reports from the business, decreasing the time the test team needs to validate the defect’s existence and reproduce it and increase the time they have to spend on working with the development team to fix the defect. “The system doesn’t work” is a pretty tough defect to reproduce, let alone fix. Ideally, your business users should be providing the steps they followed to get the defect, screen shots to help illustrate the defect, and the severity level of the defect from their perspective. That way your test and development teams have the information they need to go off and research and fix the defect.

What tips do you have for running a successful UAT cycle? Share them here!