WavebreakmediaMicro - Fotolia
Quality assurance testing vs. user acceptance testing
There are differences between QA and UAT, but testers from both sides ought to collaborate and firm up test plans to resolve issues.
In traditional, gated software development, what is the distinction between quality assurance testing and user acceptance testing?
The difference between QA testing and UAT varies across -- and even within -- organizations. However, there are some common threads that can help teams understand their responsibilities and the tenets of QA vs. UAT.
Editor's note: This article, originally published in 2008, might contain information that no longer applies for software development teams that have moved away from Waterfall or another phased code delivery approach. It was updated by site editor David Carty and test expert Amy Reichert, who explain how UAT and QA fit on Agile and DevOps teams in the section "QA and UAT in Agile."
The purpose of QA testing
QA testing usually precedes the UAT process. Developers and testers within IT organizations typically perform QA, which examines the functional behavior of individual technology components and evaluates their integrated feature-level capability.
A QA testing team should have the requisite testing skills to properly bridge technology testing with business testing. Effective QA testers evaluate software at various levels. At the technical component level, QA engineers execute functional testing, such as unit, integration and system tests, to enable early feedback. Testers can also partner with client testers at a scenario level to perform test development reviews, test data preparation and paired test execution.
After developers make changes to accommodate QA's feedback, testers can execute regression testing at any predeployment stage to check that the code or app changes did not adversely affect the software functionality.
The purpose of UAT
After QA, UAT is usually the final testing process prior to code deployment. The software development organization delivers the product to its client, which performs its own assessment of the work.
Client testers perform a UAT process to determine if the system, as tested, satisfies business needs. They attempt to execute relevant real-world scenarios. These testers communicate significant issues back to QA, and then, when it meets their requirements, they sign off on the project.
The UAT process could include several steps: alpha and beta testing, contract acceptance testing, compliance acceptance testing and black box testing.
There are several typical differences between QA testing and UAT.
Don't pit QA vs. UAT
QA and UAT testing don't need to be strictly isolated, as that could defer important feedback and reduce overall test efficiency. When possible, a collaborative testing process yields more defects earlier in the process than one in which QA and UAT are segregated, thereby giving the development team sufficient time to implement fixes and submit code for retest.
The surest way to kill a project is to view testing as a phase that belongs at the end of all the steps, as opposed to an integrated part of the ongoing development process. As DevOps and Agile take hold within more organizations, don't wait until the end to start either QA testing or UAT; that will create problems for even the simplest of projects. Nor should stakeholders look at UAT vs. QA as an adversarial relationship.
QA and UAT in Agile
Lengthy test durations lead to lengthy delays to production, which is a cardinal sin in Agile and DevOps. For that reason, a separate UAT stage is rare in modern software development, and the product owner or UX designer typically represents user or client interests throughout development.
As organizations shift to more incremental and frequent deployments, QA must also adapt with continuous testing. In Agile shops, QA engineers face a never-ending test suite. They must execute tests quickly, which includes practices like test automation, shift left and shift right. In other words, QA is less of a stage and more of an ongoing practice, with developers and testers both owning responsibility for the quality of their deliverables.
Likewise, UAT becomes more of a continuous process in Agile. Product owners might involve clients in user story creation and sprint showcases or reviews, to incorporate their feedback at multiple stages of dev and test. The final UAT stage might also exist as a sprint to address remaining defects quickly and speed deployment.
If clients are unavailable for direct feedback during a project, a UX designer can step in to represent user needs and wants and make sure a sprint hits its acceptance criteria. While UAT ideally takes place prior to release, Agile teams focus on a few steps from code creation to deployment, and even a functionality demo for the UX designer can slow release. Therefore, organizations commonly perform UAT after the release. Unless it's of critical importance, any issue found in UAT becomes a bug or enhancement request in the backlog.
Agile and DevOps teams should not think of the divide as QA vs. UAT, but rather QA and UAT. Quality is the goal for all involved, from the outset to completion and back again.
An iterative and collaborative QA testing/UAT process serves as a powerful tool to discover issues early and forecast data that helps to guide the project to successful deployment.
