User Acceptance Testing (UAT) can sometimes be seen as a “nice to have” or a low priority activity in the software development process, but it is very important to help the development team understand the customer’s and user’s perspectives. UAT is the closing of the feedback loop for how we validate that the software developed has met the user’s needs. Sadly though UAT is often left right to the end of the development process, allocated little time and assigned to people who have to squeeze it into their spare time while they do their real job. Additionally, when defects are raised during UAT they are often treated with disdain. This is really a problem in how we build software since ultimately we build software for these people. Their perspective is the one that really matters.
So what can we do about it?
- Do it earlier. An assumption that we make is that we need to have the complete system or solution available for the users to be able to complete UAT. The role of the customer in Agile has shown us that this is not true. Customers and Users are very smart and they are able to work on smaller units of work and consider the solution in its component parts. Early feedback means that all subsequent development can use the information gained in the early stages. UAT allows the injection of the customer’s perspective into the development mindset and ultimately builds a better product. Leaving it to the end is the worst time to find out if the product meets the user’s needs.
- Give people the time. UAT should be about acceptance by the users, which may involve using the solution in many ways under many conditions. If we don’t allocate enough time then people will rush to get through as much as they can and they may miss important information about the solution. We need to allow time for consideration and investigation, rather than rushing through the testing checking that the requirements have been delivered. What we need is to understand if the requirements/story has been met, not just delivered.
- Learn their language. When a defect is raised during UAT it is very difficult to manage. Late lifecycle defects are expensive and time-consuming to deal with, so often they are rejected as “enhancements” or they are deferred to the next release. This is effectively rejecting the involvement of the UAT testers and negating their input. A challenge is that the defects are often not well structured or not containing the key information that the development team needs; they are written by users, not by the development team and use the user’s language. Since this is the language of the target environment the development team needs to consider learning this language and working hard to understand each defect as it is submitted.
Post by Sharon Robson