Acceptance Testing

Acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. Acceptance testing, like system testing, typically focuses on the behavior and capabilities of a whole system or product. Acceptance testing may produce information to assess whether the system is ready for deployment and use by the customer (end-user).

Typical forms of acceptance testing are Alpha Testing, Beta Testing, Business Acceptance Testing (BAT), Contractual Acceptance Testing (CAT), Operational acceptance testing (OAT), Regulatory Acceptance Testing (RAT), and User Acceptance Testing (UAT). Organizations may use other terms as well, such as factory acceptance testing and site acceptance testing for systems that are tested before and after being moved to a customer’s site.

Objectives of Acceptance Testing

Objectives of acceptance testing include:

Establishing confidence in the quality of the system as a whole
Validating that the system is complete and will work as expected
Verifying that functional and nonfunctional behaviors of the system are as specified
Acceptance testing may also satisfy legal or regulatory requirements or standards

Test Basis

Examples of work products that can be used as a test basis for any form of acceptance testing include:

Business processes
User or business requirements
Regulations, legal contracts, and standards
Use cases and/or user stories
System requirements
System or user documentation
Installation procedures
Risk analysis reports

In addition, as a test basis for deriving test cases for operational acceptance testing, one or more of the following work products can be used:

Backup and restore procedures
Disaster recovery procedures
Non-functional requirements
Operations documentation
Deployment and installation instructions
Performance targets
Database packages
Security standards or regulations

Test Objects

Typical test objects for any form of acceptance testing include:

System under test
System configuration and configuration data
Business processes for a fully integrated system
Recovery systems and hot sites (for business continuity and disaster recovery testing)
Operational and maintenance processes
Forms
Reports
Existing and converted production data

Defects and Failures

Examples of typical defects for any form of acceptance testing include:

System workflows do not meet business or user requirements.
Business rules are not implemented correctly.
The system does not satisfy contractual or regulatory requirements.
Nonfunctional failures such as security vulnerabilities, inadequate performance efficiency under high loads, or improper operation on a supported platform

Specific Approaches and Responsibilities

Goal: The goal of acceptance testing is to establish confidence in the system, parts of the system, or specific nonfunctional characteristics of the system. Defects may be found during acceptance testing, but finding defects is often not an objective, and finding a significant number of defects during acceptance testing may, in some cases, be considered a major project risk.
Who performs it: Acceptance testing is often the responsibility of the customers, business users, product owners, or operators of a system, and other stakeholders may also be involved. At the acceptance test level,the role of a tester is often done by business analysts, subject matter experts, and users. At the operational acceptance test level, the role of a tester is often done by operations and/or systems administration staff.
Environment: Acceptance testing is performed in production like UAT environment.
When to perform: Acceptance testing is often thought of as the last test level in a sequential development lifecycle, but it may also occur at other times. For example, Acceptance testing of a COTS software product may happen when it is installed or integrated, and Acceptance testing of a new functional enhancement may occur before system testing. Acceptance testing of the usability of a component may be done during component testing.
Acceptance Testing in Iterative Development: In iterative development, project teams can utilize various acceptance testing forms during and at the end of each iteration. For example, one form is focused on verifying a new feature against its acceptance criteria and another on validating that a new feature satisfies the users’ needs. In addition, different forms of acceptance tests like alpha and beta tests, user acceptance tests, operational acceptance tests, regulatory acceptance tests, and contractual acceptance tests may occur, either at the close of each iteration, after the completion of each iteration, or after a series of iterations.