In software engineering and the various disciplines, acceptance testing is black-box tests conducted on a system (eg software, manufactured mechanical parts, or batches of chemical products) prior to delivery. It is also known as functional testing, black-box testing, release acceptance, QA testing, application testing, confidence testing, testing, validation testing, or factory acceptance testing.
In software development, acceptance testing of the system testers are often distinguished from acceptance testing by the customer (the user or client) before accepting the transfer of ownership. In such environments, acceptance testing performed by the customer is known as user acceptance testing (UAT). This is also known as end-user testing, site (acceptance) testing, or field (acceptance) testing.
Acceptance testing is generally running a suite of tests on the completed system. Each individual test, known as a case, exercises a particular operating state of the environment of the user or feature of the system, and will result in a pass or fail with Boolean outcome. There is generally no degree of success or failure. The test environment is usually designed to be identical, or as close as possible to the expected user environment, including those extremes. These test cases, each accompanied by test case input data or a formal description of the operational activities (or both) intended to conduct a thorough practice-specific case and a formal description of the expected results.
Acceptance Testing Criteria are generally prepared by corporate customers and business domain expressed in a language. These are high level tests to the completeness of a user story or stories test “played” during test iteration. These tests are ideally created through collaboration between business clients, business analysts, testers and developers, but business customers (product owners) are the principal owners of these tests. If the user stories pass their acceptance criteria, one can be sure that the developers are progressing in the right direction on how the application was considered to work. So it is essential that these tests include both business testing and validation UI logic elements (if necessary).
Acceptance Test cards are ideally created during test planning meeting, before development begins, so the developers have a clear idea of what to develop. Sometimes (due to poor planning!) Acceptance testing can span multiple stories (that are not performed in the same test iteration) and there are several ways to test them during the actual test cycle. A popular technique is to mock external interfaces or data to mimics other stories, which can not be played during an iteration (as these stories may have been relatively lower priority cases). A user story is not considered complete until it has passed the user acceptance testing.
The acceptance test suite is run against the supplied input data or using an automatic acceptance test script to direct the testers. then the results is compared with the expected results. If expected result matches then the test suite is said to be passed. If not, the system can either be rejected or accepted conditionally based on previously agreement between the customer and consulting company.
The goal oof UAT is to provide confidence that the system delivered the business needs of both sponsors and users’ requirements. The acceptance phase may also act as the final quality gate, where previously detected defects can be uncovered.
An important goal of the UAT is that, once successfully executed, and certain additional (contractually agreed) acceptance criteria are met, the sponsors will then sign off on the system to meet the contract (previously agreed between the client and manufacturer), and make final payment.
User acceptance testing
User Acceptance Testing (UAT) is a process to obtain confirmation by a Subject Matter Expert (SME), through trial or investigation, that the change or addition to each agreed requirements are fine and as per the contractual agreements. In software development, UAT is one of the last phases of a project and often occurs when a client or customer accepts the new system.
The results of these tests give confidence to customers about how the system will perform in production. There may also be legal or contractual obligation to accept the system.
Types of acceptance testing
Typical acceptance tests include the following:
User acceptance testing
This is the factory acceptance testing, that is the test done by the user before the factory plant is moved to its own site, and the site acceptance tests can be performed by users on the site.
Operational Acceptance Testing
Also known as operational readiness testing, this refers to the monitoring done for a system to ensure that processes and procedures for the system to use and maintain. This can also done to control the back-up facilities, procedures for disaster recovery, end user training, maintenance procedures and safety procedures.
Contract and regular acceptance testing
In order acceptance testing, a system is tested against acceptance criteria as documented in a contract, before the system is accepted. In regulation acceptance testing, a system is tested to ensure that the public, legal and safety standards.
Alpha testing takes place in developers’ site, and involves the testing of the operating system by internal staff, before being released to external customers. Beta testing will take place at client sites, and involves testing a group of customers who use the system on their own sites and give feedback before the system is released to other customers. The latter is often called “field tested”.
- Acceptance Test Engineering Guide by Microsoft patterns & practices
- Article Using Customer Tests to Drive Development from Methods & Tools
- Article Acceptance TDD Explained from Methods & Tools
- ITIL Definition – Release Acceptance (a sub process of Release Management) — The Activity responsible for testing a Release, and its implementation and Back-out Plans, to ensure they meet the agreed Business and IT Operations Requirements.