What is User Acceptance Testing?

User acceptance testing (UAT) describes the testing that occurs after the development team has completed its work and typically follows the Quality Assurance (QA) process. Rather than including QA steps like verifying that the software achieves its requirements, executes properly, performs its calculations, and does not return errors when users click buttons and input values, UAT looks for users to use the software in a real-world setting.

Although UAT does not primarily focus on the technical competence and accuracy of the software, it can offer an extra layer of protection if the QA testers have missed some technical issue.

Why do you need QA and UAT?

QA testing can verify that software fulfills the software requirements as they have been documented at the beginning of a software project. However, for most software projects, it’s common for someone other than the end-user to provide the software requirements. It’s entirely possible that the software still won’t satisfy the needs of users even when it meets every requirement exactly as specified at the beginning of the project. This often happens when the person who wrote the requirements did not fully understand how the end-user would use the software or even what their actual needs were.

This is where user acceptance testing proves its value. UAT is a great way to validate that the entire development process worked—from the day that the requirements were first written through the actual coding. UAT becomes that final test to verify a software’s fulfillment of a user’s needs before go-live.

What potential UAT shortcomings should I watch for?

If users find issues and challenges during UAT, it does not necessarily mean that these are bugs in the software. These could represent missed requirements or differences in how the software was designed versus what the end-users were actually looking for. Of course, occasionally, an issue or challenge found during UAT is a true technical bug.

User acceptance testing can be a great source of validation that comes as the development of a software project nears its close. But, UAT can also be a great source of scope creep. We often see that just because the user wants the software to work a certain way, that need may not reflect the intended scope of the project or just be one user’s opinion.

This is why we do not recommend a direct line of communication between the user acceptance tester and the development team. If we were to establish that direct line of communication, we open the door to a lot of opportunities for scope creep.

Unlike QA testers, users participating in UAT are not creating formal issues or tickets from their testing. Users are not as fluent in the information that developers need or want to understand or address issues and recreate the problem. They also may not know the information that is needed to resolve issues as quickly as possible. UAT testers are not as tightly integrated with the development team or trained in testing.

What happens when UAT issues come up?

While user acceptance testing usually create an issues list, the issues are usually not appropriately structured or documented to go directly to the development team. End-users work in their business language and do not always understand how the software works. They rarely provide the level of detail that a developer needs to put that issue into development.

Typically, the output of user acceptance testing must go back through a requirements owner or a QA tester who then reviews the results and translates issues into what developers need to see. Additionally, because end-users are not just testing functionality, they may be saying what they want or expect the software to do. They may be asking for functionality that falls outside a business owner’s intended design and scope.

Learn more about UAT and software development

User acceptance testing is critical in validating the effective and efficient functioning of new software. An effective UAT process builds alignment between the development team and end-users and engages people who were not part of the development team in the process to create new solutions. UAT is a chance to validate the fulfillment of all requirements. In a software delivery model that is truly iterative, the UA team sees each deliverable throughout the development project. Before a software project gets approved and pushed into production, it should pass through UAT to ensure that it meets not just the project’s requirements, but the underlying needs of the users.

Would like to learn more about our approach to User Acceptance Testing and custom software development?  Get in touch and let’s talk.

Thayer Tate

Thayer is the Chief Technology Officer at SOLTECH, bringing over 20 years of experience in technology and consulting to his role. Throughout his career, Thayer has focused on successfully implementing and delivering projects of all sizes. He began his journey in the technology industry with renowned consulting firms like PricewaterhouseCoopers and IBM, where he gained valuable insights into handling complex challenges faced by large enterprises and developed detailed implementation methodologies.

Thayer’s expertise expanded as he obtained his Project Management Professional (PMP) certification and joined SOLTECH, an Atlanta-based technology firm specializing in custom software development, Technology Consulting and IT staffing. During his tenure at SOLTECH, Thayer honed his skills by managing the design and development of numerous projects, eventually assuming executive responsibility for leading the technical direction of SOLTECH’s software solutions.

As a thought leader and industry expert, Thayer writes articles on technology strategy and planning, software development, project implementation, and technology integration. Thayer’s aim is to empower readers with practical insights and actionable advice based on his extensive experience.