You have to know where you are going BEFORE you get on the flight.

You have to know where you are going BEFORE you get on the flight.

All forms of user acceptance testing reduce project risk. Agile user acceptance testing just does it better. I could stop here and this would a short entry today, but I guess I’ll go ahead and make my point.

User acceptance testing (UAT) is most effective in reducing two forms of risk. The first is the risk of doing the wrong thing. In user acceptance testing, users interact with the software (or product) and make sure that it accomplishes what they need. Simply put, if the project team builds something that does not accomplish what the project stakeholders require, no business value is delivered. The second major form of risk that UAT targets is the risk of doing the right thing the wrong way. Assuming that the team has solved the proper business problem the solution needs to be delivered in a manner that can be used. Functionality with a poor UX or form factors might be technically correct, but is less valuable than it could be.

Classic user acceptance testing is done at or very near the end of the project and is based on the project requirements. The classic testing V-Model shows the progress from requirements to code and the linkages between deliverables and the tests that are based on those deliverables. The problem in the process that is inferred from the V-Model is twofold. The first is the feedback delay that is caused by waiting until the end of the project in order to test for acceptance. Ultimately the act of testing reduces the risk of delivering both the wrong thing and the right thing done wrong. The risk is dealt with by finding problems and rework at the end of the project, which if there are deadlines can cause secondary problems.  Pressure and stress can lead to shortcuts, technical debt and worse – defects that impact production. The second problem is the implied separation of the user acceptance test cases from the requirements. Organizations that consider user acceptance tests cases as a separate deliverable from the requirements typically forgo the knowledge that integrating the two documents provide.  In some organizations proxies, such as independent test groups (not real users), develop user acceptance test cases based on their interpretation of the requirements. This further foregoes possible feedback until the tests are executed, but at least the final user acceptance test provides an avenue to connect the requirements, test cases and functionality through the execution of acceptance testing, albeit late in the process .

Agile user acceptance testing builds on the risk reduction properties of the classic UAT. Acceptance criteria are written as part of a user story directly linking what is needed with how it will be proved. Linking the story and the acceptance criteria creates an unavoidable feedback loop that reduces both the risk of building the wrong thing or the right thing wrong. The combination of a definition of done that includes acceptance testing and Agile’s short time boxes that deliver potentially shippable functionality means that acceptance testing is performed as part of each sprint. The test-early-and-often mantra generates feedback that reduces risk earlier in the project. Finally, given that acceptance criteria are usually executed over and over as the project evolves, acceptance criteria are subject to heavy scrutiny. This helps make sure they are testing the right concepts in the software.

User acceptance testing reduces project risk. Regardless of whether you are doing Agile, lean, waterfall or something in-between, you should be doing UAT. However if you want to be truly effective and efficient, Agile user acceptance testing is far superior to other methods.