Quality assurance testing vs. user acceptance testing (original) (raw)

WavebreakmediaMicro - Fotolia

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.

How QA differs from 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.

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.

Next Steps

How SIT and UAT rely on different roles, skills

Regression testing vs. UAT: Goals and techniques