AAA Toolbox: Acceptance Criteria
04 Mar 2012Esse é um post de uma série que eu compartilhei internamente na ThoughtWorks uns anos atrás. Eu escrevi em inglês, então republico assim, mas se a série acabar sendo bem popular, eu prometo traduzir tudo.
Stories are a key artefact of agile business analysis, but in order to complete the validation loop, it is useful to describe what changes in the system are expected after the story is played. Stories in cards can be quite abstract and, therefore, hard to verify if the corresponding code does what is expected out of it. Instead, an analyst can write scenarios that describe the expected behaviour.
Mike Cohn called these scenarios "acceptance tests", and suggested using one-liners to describe the tests that should be performed. Dan North came up with the concept of Behaviour Driven Development, and as part of it, the standard format for scenarios in user stories. Much like the As a... I want to... So that... model, he proposed a "Given... When... Then..." template for writing acceptance tests and called them Acceptance Criteria. The "Given" part is used to set the stage (i.e.: describe the initial state of the pertinent variables); the "When" part to describe the event that triggers a change in the system covered in the story; and the "Then" bit to describe what is the perceived change in the system after the triggering event occurred, given the initial state of the system. For instance:
Given the user is on the "place car reservation" page
and the "customer name" field is not empty
When user follows the "complete reservation" link
Then user is directed to "car reservation confirmation" page
Other acceptance criteria for this story could cover what happens if the customer name field is empty, or what can be seen in the confirmation page. Acceptance criteria can be bound to implementation a lot more than stories should be. Ultimately, they should describe everything that is expected of the story. Analysts should make an effort to guarantee that acceptance criteria are not missed (by performing edge case analysis, reviewing with the product owner or other methods), as missed acceptance criteria will not be tested, therefore, even if implemented, cannot be guaranteed to work after changes in code.
Stories normally have several acceptance criteria. These acceptance criteria should be as atomic and unambiguous as possible. It is very unlikely that an "or" will be used in an acceptance criteria. In most cases where it would make sense to use it, it is advisable to split these conditions in multiple acceptance criteria. Similarly, "and" connectors in the "When" and "Then" clauses usually indicate that the acceptance criteria could be re-written or broken down. Of course, these are only smells that something is off and shouldn't be considered hard and fast rules. Ultimately, the acceptance criteria style should be agreed among the team based on the type of automated test being used.