Acceptance Testing

Profile picture for user devraj

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. 

Table of Content

  1. Objectives of Acceptance Testing
  2. Test Basis
  3. Test Objects
  4. Defects and Failures
  5. Specific Approaches and Responsibilities
  6. Video Tutorial

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.