Acceptance testing is generally taken to mean the formal phase of testing conducted to enable an authorised entity to determine whether to accept a system, component or solution. Acceptance testing is important because it determines if a supplier has delivered what was agreed between the customer and the supplier.

There can be many different types of acceptance testing for a system, service or product, The main types of acceptance test are:

Business Acceptance Testing (BAT)

Business acceptance testing determines if the product or service meets the business goals (including requirements that have been specified and those that are implicit). Acceptance tests focus on ensuring that the implementation has the scope to deliver the business benefits. These benefits are typically financial targets or higher level expectations (such as “this application will enable 90 per cent of customers phoning the call centre to use the SAP web interface and conduct the transactions on-line”).

A new product or service that meets all its stated technical requirements might still fail the business acceptance test. Often this is due to changing market circumstances, and the planned system implementation is either cancelled or enhanced before it goes live.

Contract Acceptance Testing

Contract acceptance testing can take place either before a service goes live, or after it has been live for a pre-determined period. The tests demonstrate that the supplier has met the stated requirements of the contract. Normally payment is linked to succesfully passing the acceptance tests.

When conducted after a service is live, the contract usually references a service level agreement (SLA), which describes the service delivered rather than the mechanism by which the service is delivered.

Customer Acceptance Testing (CAT)

Customer acceptance testing is conducted by the customer of a product or service prior to accepting the product or service meets their stated, and sometimes unstated needs. CAT is usually conduced in the period immediately before going live.

Customer acceptance testing differs from user acceptance testing, (UAT), because the customer is usually a company that has previously committed to accepting the product or service, subject to the service meeting their needs. The customer may not be the final user of the tested product or service.

Factory Acceptance Testing (FAT)

Factory acceptance testing (FAT) is the process of in-house (or in-factory) testing that determines the product or part meets the stated specification. This testing is conducted by the suppliers prior to shipment of the product to the customer.

FAT is commonly used to describe testing conducted on parts or components shipped in engineering industries, but can also be used when developers are testing software or software/hardware combinations prior to shipment to a customer.

Operational Acceptance Testing (OAT)

Operational acceptance testing is usually conducted as part of the overall acceptance test phase, typically performed in a (simulated) operational environment by operations and systems staff. OAT tests day to day operational aspects, including recoverability, resilience, installability, memory-usage and technical compliance. Typically, the operational processes will be tested at the same time.

Production Acceptance Testing (PAT)

Production acceptance testing is conducted as part of the overall acceptance test phase, immediately prior to the product being moved into production. The tests focus on making sure that the production units are of consistent quality and are equivalent to the product that has been tested (and accepted) and that they are free from manufacturing defects.

Whilst PAT is very important during the tests for devices that are combinations of hardware and software, it is still an important consideration for software services where either there are printed documents or physical distribution is used.

Regulatory Acceptance Testing

Regulatory acceptance testing can take place either before a service goes live, or after it has been live for a pre-determined period. The tests demonstrate that the supplier has met the stated requirements of the contract. Normally payments are attached to the tests passing.

Site Acceptance Testing (SAT)

This is acceptance testing by users or customers at their own site, to determine whether or not a component or system satisfies the user/customer needs and maps correctly to the agreed business processes. Normally this includes testing the hardware as well as software components.

Effective SAT is built on all the other types of tests that have been performed before formal site acceptance testing takes place. This would include the functional and non functional criteria. A reasonable goal of SAT is not to re-produce all the previous tests, but use them as evidence to support site acceptance.

User Acceptance Testing (UAT)

UAT is a phase of formal testing conducted to enable a user or other authorised entity to determine whether to accept a system or component. Often known simply as acceptance testing (or sometimes customer acceptance testing), the UAT is usually based upon business requirements.

The key word is “user” – for satisfactory UAT to take place, real users should be used. Typically, the following problems arise:

• The users are too busy to test, so delegate the activity to teams who may not have the capability to identify what should be tested
• The testing focuses on the functional requirements alone. Users must accept the service if it meets the specifications, irrespective of whether it meets their needs
• No non-functional tests are run, so the system does not work under all the required circumstances

Acceptance testing issues

Acceptance testing encompasses one or more of the above activities and is regarded as representing the overall acceptance of the solution.

Acceptance testing normally takes place towards the end of the development life-cycle, just before deployment. As such, there are often competing pressures between completing this stage quickly and performing it thoroughly enough to ensure that the system is fit for purpose. (In most contracts it is stipulated that if the acceptance testing is not completed within a specified period then the system is deemed to have been accepted). This pressure may cause the customer and supplier relationship to breakdown, particularly if commercial decisions have to be made against weak or inadequate acceptance criteria when there is little time left in the project. For example, the acceptance tests that are executed and passed may not necessarily demonstrate that the system is actually fit for purpose.

Acceptance testing may throw up serious problems and bugs that prove difficult and time consuming to resolve at this late stage. And there are alternatives to conducting acceptance testing in a time pressured phase at the end of the programme of change. Acutest's Progressive Acceptance Testing approach enables many of the activities and stages of acceptance testing to be brought forward into earlier stages of the project reducing the delay of the acceptance testing and improving control and governance.