Also: Functional test, customer test
Pass/fail tests used to define whether or not a feature is functional, usually developed in parallel to the defining of a feature. These tests may be written in plain English by the customer or product owner (“The user clicks , the session is reset, and the user is redirected to the homepage.”) Ideally, an acceptance test is subsequently automated by the developer so that it can easily run on all iterations of the software, ensuring that the accepted feature has not been broken by newer development. The use of acceptance tests in subsequent iterations is also known as regression testing. Acceptance testing is a key feature of test-driven development (TDD).
In Scrum: Scrum does not specify testing methods, and testing is not a part of the Scrum framework. This said, most Scrum teams test, and within the Scrum framework, the product owner would be the appropriate person to define acceptance tests.
The concept of acceptance testing exists in other engineering disciplines than software development, and is usually referred to as black-box testing.
Although acceptance testing is common across many Agile disciplines, the term derives from XP. According to C2.com, acceptance tests were first referred to as functional tests, because they test whether or not a feature works. Kent Beck, a primary mover behind TDD, proposed the change in terminology in April 2000.