User acceptance testing (UAT)

validating the fitness for use of the
system by intended users in a real or simulated operational environment. The main objective is building
confidence that the users can use the system to meet their needs, fulfill requirements, and perform
business processes with minimum difficulty, cost, and risk

Specific approaches and responsibilities

Acceptance testing is often the responsibility of the customers, business users, product owners, or
operators of a system, and other stakeholders may be involved as well.

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 occur when it is installed or integrated

Acceptance testing of a new functional enhancement may occur before system testing

Operational acceptance testing (OAT)

The acceptance testing of the system by operations or systems administration staff is usually performed
in a (simulated) production environment.

Test focus on: Testing of backup and restore, Installing, uninstalling and upgrading, Disaster recovery, User management, Maintenance tasks, Data load and migration tasks, Checks for security vulnerabilities, Performance testing

The main objective of operational acceptance testing is building confidence that the operators or system
administrators can keep the system working properly for the users in the operational environment, even
under exceptional or difficult conditions

In iterative development, project teams can employ various forms of acceptance testing during and at the
end of each iteration, such as those focused on verifying a new feature against its acceptance criteria and
those focused on validating that a new feature satisfies the users’ needs. In addition, alpha tests and beta
tests may occur, either at the end of each iteration, after the completion of each iteration, or after a series
of iterations. User acceptance tests, operational acceptance tests, regulatory acceptance tests, and
contractual acceptance tests also may occur, either at the close of each iteration, after the completion of
each iteration, or after a series of iterations.

Contractual and regulatory acceptance testing

Contractual acceptance testing is performed against a contract’s acceptance criteria for producing
custom-developed software. Done by users or by independent testers

Acceptance criteria should be defined when the parties agree to the
contract. Contractual acceptance testing is often performed by users or by independent testers.
Regulatory acceptance testing is performed against any regulations that must be adhered to, such as
government, legal, or safety regulations. Regulatory acceptance testing is often performed by users or by
independent testers, sometimes with the results being witnessed or audited by regulatory agencies.
The main objective of contractual and regulatory acceptance testing is building confidence that
contractual or regulatory compliance has been achieved.

Read More >

Alpha and beta testing

Alpha and beta testing are typically used by developers of commercial off-the-shelf (COTS) software who
want to get feedback from potential or existing users, customers, and/or operators before the software
product is put on the market. Alpha testing is performed at the developing organization’s site, not by the
development team, but by potential or existing customers, and/or operators or an independent test team.
Beta testing is performed by potential or existing customers, and/or operators at their own locations. Beta
testing may come after alpha testing, or may occur without any preceding alpha testing having occurred.
One objective of alpha and beta testing is building confidence among potential or existing customers,
and/or operators that they can use the system under normal, everyday conditions, and in the operational
environment(s) to achieve their objectives with minimum difficulty, cost, and risk. Another objective may
be the detection of defects related to the conditions and environment(s) in which the system will be used,
especially when those conditions and environment(s) are difficult to replicate by the development team

Read More >