Formal testing conducted to enable a user, customer or other authorized entity to determine whether to accept a system or component.

[IEEE]BS 7925-1.British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST).

Overview.
Acceptance testing is high up on the V model, a counterpart to the requirements specification process. There are two types Business Acceptance and User Acceptance. Historically this element of testing comes at the end of the development lifecycle. However with an understanding of risk it is apparent that closer and more timely appreciation is needed. .

User Acceptance Testing
User Acceptance Testing (UAT) is the highest level of test. Matters affecting UAT include contracts, the degree to which the "User" agrees that the development organisations testing is sufficient, the testing maturity and the amount of integration needed with existing systems.

Actual planning and execution of the test does not have to be undertaken directly by the customer. Many test consultancies offer their services to do this.

Business Acceptance Testing (BAT)
BAT is undertaken within the development organisation. The aim is to ensure that the software will eventually pass acceptance test.

Practice
Many forms of testing can be included in the grand scheme of Acceptance Testing. Functional and non-functional. Manual and automated.

The chosen combination of test techniques and the resources devoted to them are dependent such factors as complexity, size and risk attributable to the software. Thus if performance and reliability is an issue, automated testing may be used to simulate large numbers of users logging on to the system, whilst at the same time a test team is formed of end users to manually input test cases, based on real-life data.

Risk and Planning
If we look at the V model above, we can see the large gap. In the traditional waterfall method this produces a tremendous risk. The customer turns round and says "you have built it wrong. We are not accepting it and definitely not paying for it." The development organisation has to keep this in mind at all times, whilst the product is in development and to factor it into their planning. Errors in the process can cause headaches for both the customer and the software producers. The customer may have business practices due to roll which are dependent on the software performing in a certain way.

Models
I have mentioned the Waterfall and V-models as a lifecycle models. Another important method is Iterative. How each model treats acceptance by the customer is interesting.

In the waterfall the customer is always the last step in the process. Everything is fine if the software passes Acceptance Testing. However major problems can arise if it fails.

Although it is implied that the V-model will follow the sequential flow of requirements capture, design...unit test ... system test..acceptance test. This is not necessarily the case. It should in my opinion be considered a mapping framework where the test process maps on to the development process. Thus the as soon as the requirements phase is over the customer can view the requirements specification to agree that they have been correctly captured, reducing the risk of the supplier building the wrong thing.

The iterative model, as personified by the Rational Unified Process, takes this one stage further and formally puts the customer as a stakeholder right in the middle of the process. Thus in the inception phase the customer helps in scoping the project and identifying important use cases. In Elaboration, the customer as a stakeholder is further involved in developing use cases. Thus during the Transition phase when formal acceptance testing is taking place a lot of the risk should have been removed.