Acceptance tests are from the user’s point of view – the external view of the system. They examine externally visible effects, such as specifying the correct output of a system given a particular input. In general, they are implementation independent, although automation of them may not be. Acceptance tests are a part of an overall testing strategy.
Acceptance tests are created when the requirements are analyzed and prior to coding. Failing tests provide quick feedback that the requirements are not being met. The tests are specified in business domain terms. The terms then form a ubiquitous language that is shared between the customers, developers, and testers. Tests and requirements are interrelated.
A requirement that lacks a test may not be implemented properly. A test that does not refer to a requirement is an unneeded test. An acceptance test that is developed after implementation begins represents a new requirement. Acceptance criteria are a description of what would be checked by a test.
Given a requirement such as “As a user, I want to check out a book from the library”, an acceptance criterion might be “Verify the book is marked as checked out.” An acceptance test for this requirement gives the details so that the test can be run with the same effect each time.
No comments:
Post a Comment