What is
Acceptance Testing??
Acceptance
testing mainly focuses on the behavior and
capabilities of a whole system or product.
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.
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 non-functional behaviors of the system are as specified
Acceptance
testing may produce information to assess the system’s readiness for deployment
and use by the customer (end-user). 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.
Below are the Types of Acceptance Testing:
Ø User acceptance testing (UAT)
Ø Operational acceptance testing
Ø Contractual and
regulatory acceptance testing
Ø Alpha and beta testing.
User
acceptance testing (UAT)
The
acceptance testing of the system by users is typically focused on 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.
Operational acceptance
testing (OAT)
The
acceptance testing of the system by operations or systems administration staff
is usually performed in a (simulated) production environment. The tests focus
on operational aspects, and may include:
Ø 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.
Contractual and
regulatory acceptance testing
Contractual
acceptance testing is performed against a contract’s acceptance criteria for
producing custom-developed software. 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.
Alpha
and beta testing
Alpha
and beta testing is typically used by developers of commercial off-the-shelf
(COTS) software that 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 has occurred.
One the 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.
Now
the obvious question that comes to our mind was on what basis or documents Acceptance
testing could be performed:
Ø Business processes
Ø User or business
requirements
Ø Regulations, legal
contracts and standards
Ø Use cases
Ø System requirements
Ø System or user
documentation
Ø Installation procedures
Ø Risk analysis reports
What kind of Issue Can be identified by Acceptance Testing??
Ø System workflows do not
meet business or user requirements
Ø Business rules are not
implemented correctly
Ø System does not satisfy
contractual or regulatory requirements
Ø Non-functional failures
such as security vulnerabilities, inadequate performance efficiency under high loads, or improper
operation on a supported platform
