The classic definition of a user acceptance test (UAT) is a process that confirms that the output of a project meets the business needs and requirements. UAT in an Agile project generally is more rigorous and timely than the classic end of project UAT found in waterfall projects. In waterfall projects, the UAT is usually the last step in the development process. The problem with that classic scenario is that significant defects are found late in the process, or worse, the business discovers that what is being delivered isn’t exactly what they wanted. Agile projects provide a number of opportunities to interject UAT activities throughout the process, starting with the development of user stories, to the sprint reviews and demos, and finally the UAT sprints at the end of a release. Each level provides a platform for active learning and feedback from the business.
Agile UAT begins when user stories are defined. A user story should include both story and acceptance test cases (also known as acceptance criteria). As noted in Daily Process Thoughts, July 31, 2013, one technique for creating and grooming user stories is called the Three Amigos. This technique gathers a representative from the business, professional testing and development so that all major constituencies are represented. As a story is defined, so are the acceptance criteria. Adding the focus on business acceptance criteria during the definition of user stories begins the UAT process, rather than waiting until later in the project. Laying out the acceptance criteria when you begin work on a story creates a focus that helps the team to stay focused on what is actually needed and reduces the potential for rework and gold plating (adding extra features).
A second layer of UAT in Agile projects is found in the end of sprint demonstration. The Daily Process Thoughts, June 20, 2013, provided a description of typical demonstration (also known as a show ‘n’ tell or sprint review activities). As a reminder, demonstrations are planned so that the product owner and team can provide proof that they have solved the business need. Demonstrations are interactive so that stakeholders can provide feedback and buy into the solution. Another technique that many Agile teams add to their working process is adding UAT tasks for each story. This ensures another level of user interaction as part of the development process, thereby increasing feedback and acceptance. In both cases the interaction at the end of sprint is earlier than is common in waterfall projects.
The third level of UAT is the inclusion of a dedicated sprint to perform a final, overall user acceptance test. In this scenario, the units of work defined for the sprint would be focused on test cases or scenarios and then fixing any discovered defects. Having a sprint focused on UAT has risks. The risk is that delaying UAT until a specific sprint increases the probability of finding problems that require substantial rework later in the cycle, where they are more costly to fix. This is the same basic issue with the placement of the UAT in a waterfall project. So why do it? One of the reasons this approach might be needed is where users need to validate the entire system before acceptance (this happens in life critical systems and in many regulated markets). Developing stories with acceptance test cases, ensuring interaction with stakeholders at demos and adding user acceptance tests task in order for stories to be completed will help minimize the need for a specific UAT sprint and mitigate most of the risks of this technique when you have to use it.
User acceptance testing is at least as rigorous in Agile project as in most waterfall development techniques. As importantly, Agile UAT techniques are applied much earlier in the development process providing earlier feedback to the team. Earlier feedback reduces rework by finding and fixing problems before they can get bigger. Many Agile UAT activities are part of the standard Agile practices including acceptance test cases in user stories and generating interactions with stakeholders in demonstrations. When need extra activities are easily integrated into Agile development techniques such as adding UAT tasks in developing stories or include UAT specific sprints. UAT activities build trust with stakeholders. UAT also proves to stakeholders that were not involved in the Agile development process that project is delivering on the business needs. User acceptance testing is a necessary step in any project, Agile just spreads it out and does it earlier (and better).