Introduction to the 'Acceptance Testing' category.

Acceptance testing is based on acceptance criteria agreed with the customer for an IT system.

All requirements should have a corresponding set of acceptance criteria defined for them. Thinking of requirements in terms of what is needed to test them is an excellent discipline; along with defining a rationale for every requirement, the inclusion of acceptance criteria is a starting point for writing better requirements. Note by the way that if there is no rationale for a requirement, then the acceptance criteria are irrelevant.

Carefully considered acceptance criteria will prevent the possibility of untestable requirements being agreed with the customers and subsequently put forward to developers and testers. They are a form of immediate review of the quality of the requirements.

Agile development practices have highlighted the importance of acceptance criteria. However, even before the advent of agile, teams who knew how to define rigorous requirements have always insisted on their inclusion; see for example, early editions of 'Mastering the Requirements Process' by the Robertsons who recommended the use of so called, 'fit criteria'.

There are various forms of acceptance testing. Perhaps the best known is 'User Acceptance Testing' (UAT). This should always involve users but is often performed by the test team or by business analysts.

Other levels of testing should have been performed before acceptance testing starts. Although a system can never be declared error free, these earlier tests should have discovered the majority of the errors. The primary objectives of acceptance testing are typically about giving the customers confidence that the product works, rather than about finding bugs.

Articles on the subject of acceptance testing and related topics