 Acceptance tests are created
from user stories. During an iteration the user stories selected during the iteration
planning meeting will be translated into acceptance tests. The customer specifies
scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests,
what ever it takes to ensure the functionality works.
Acceptance tests are black
box system tests. Each acceptance test represents some expected result from the system. Customers are responsible
for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are
of highest priority. Acceptance tests are also used as regression tests prior to a production release.
A user story is not considered
complete until it has passed its acceptance tests. This means that new acceptance tests must be created each iteration
or the development team will report zero progress.
Quality assurance (QA) is
an essential part of the XP process. On some projects QA is done by a separate group, while on others QA will be
an integrated into the development team |
itself. In either case XP requires development to have much closer relationship with QA.
Acceptance tests should
be automated so they can be run often. The acceptance test score is published to the team. It is the team's responsibility
to schedule time each iteration to fix any failed tests.
The name acceptance tests
was changed from functional tests. This better reflects the intent, which is to guarantee that a customers requirements
have been met and the system is acceptable. 
  |
