When you buy through affiliate links in our content, we may earn a commission at no extra cost to you. Learn 
Demo And Die!
Have you ever delivered a customer presentation or training, and something breaks halfway through? Or, have you ever given someone a set of instructions and realized you missed something, or it didn’t quite work as you’d hoped? During each of these instances, you adopt the perspective of the end user and work with the software in that persona. Chances are, you did something differently because you were thinking as a user, rather than a developer.
Step Into the User’s Shoes
The unique angle of user acceptance testing (UAT) is to test software as an end user. Software is built to give users tangible results. For example, e-commerce sites allow customers to purchase products. When a customer places an order, the e-commerce site’s software notifies the store administrator, so that the selected item can be pulled and packed for shipment. There may be different types of software users, so this testing stage allows the development team to verify that end users achieve expected software results.
A Brief UAT History
Before the advent of the internet, most software was deployed for a known user audience. If a company developed software for a customer, an assigned manager had the authority to verify that the software fulfilled the contract terms. This was meant to represent a point where the software was “fit for purpose,” which was achieved by selecting end user representatives to perform testing and provide a report with results. Because the users were a known, closed group, each could be trained in the use of the software, typically through very detailed test steps. The motto of the day was that more detail was better.
As more and more software was developed for customers on the web, the end user audience became more open. It was no longer possible to identify and train all likely end users, so software design had to include a much greater emphasis on usability and had to be easily understandable – even with minimal provided information. So, UAT had to change to meet these requirements.
UAT Tells You How Usable the System Is
So, not only does UAT tell us the extent of functionality for a piece of software, but it also tells us how usable it is. Most UAT is best performed by individuals who understand the targeted end user that will experience the software with little prior knowledge and can give a true indication of the software’s ease of use and what needs improvement.
Who Can Perform UAT?
As developers test software, they remember details about how a system is written. This knowledge can influence testing, and developers may take different steps than end users, such as performing steps more quickly or dismissing fine details that end users may find confusing. Thus, developers are not the best UAT candidates. So, who is?
Many organizations employ specific testing teams that are not involved in technical design and development. Smaller organizations either allocate testing to non-development staff, like those who perform administrative duties, or use the services of an outside company. Some organizations use what is known as “hallway testing,” where they literally hand pick staff members that are not actively employed on the project and ask them to try the system from the end user’s perspective. An example would be ordering product online.
After in-house testing, pilot or beta testing stages can occur, whereby the software is made available to small groups of “real” users who are invited to use the product for free or at a significant discount, in return for detailed usage feedback.
Progressive UAT stages with varied audiences increase confidence in software usability. Combined with phases of iterative development, multiple UAT cycles can be performed to test new features as they are delivered, while verifying previous functionalities.
Good UAT testers are curious to see what happens if they take different routes to a particular goal. After all, everyone approaches the use of software in different ways, so if many possibilities can be covered by a small group of people, the confidence of the software in operating mode is higher.
Success And Failure Flows
UAT processes should verify that each type of software user gains the tangible results required for both success and failure flows.
In a success flow, an end user walks away with an expected result, such as placing a product order. In a failure flow, the software supports the end user through some form of error scenario, such as when a customer provides invalid credit card payment information.
To verify functionality, some information must be provided to testers. Otherwise, they don’t know what the software is supposed to do. But to test usability, this must be minimal – just task or requirements based, such as buying “x” (product) and paying “y” (using credit card details). The onus must be placed on testers to record observations, successes and failures.
UAT Benefits
A key benefit of good UAT is that it keeps ongoing maintenance costs as low as possible. It’s cheaper to fix functionality and usability issues early. It’s much harder to fix a bug when there is more code around it to regression test or if the original developer is unavailable.
UAT that is performed in multiple stages and with different types of test audiences provides optimal opportunities to identify and repair broken features/usability issues in the early phases of testing. Keeping UAT goals at task and requirement level allows testers to observe and notice much more and even attempt steps outside the developer’s provided scope.
Feedback from UAT cycles can be fed into subsequent iterations of development, increasing software robustness and usability. Timed well, even beta test phases can complement marketing and sales activities by providing references and case study feedback.
