Defining the DoD
Agile teams tend to have a hard time while defining the Definition of Done – DoD of user stories (user requirements). The user requirements are defined, documented, approved and passed on to the development team for estimation and implementation (coding). But how can the agile team clearly state that they delivered what was defined on user stories? How to set the Definition of Done ?
Acceptance Test Suite
An awesome way to accomplish this is by having a solid suite of user acceptance automated tests. It makes an easy task to prove that the customer usage scenarios are complete and working as expected, in other words, you are delivering value for them (and the right value). Those kind of tests are better expressed/written by using the Gherkin language, thus forming a live and dynamic documentation.
Live documentation
For example, when a requirement is updated, the corresponding test scenarios should also be updated, making sure that the software behaviour is updated, reflecting the new requirement. If a test fails, a requirement fails. If a test pass, it proves that the user story is complete and correctly implemented.
Drive TDD
Acceptance tests can also drive the software development, helping developers on knowing how to start the unit test scenarios (a common developer doubt).
Value is delivered from early phases
The acceptance tests scenarios should be written before development starts, they leverage team communication from start to the end of the development cycle.
Andrew Premdas, one of the first adopters of Cucumber, says it well:
Your cucumber features should drive your implementation, not reflect it.
Delivering a requirement is demonstrating that it is working as expected, guaranteeing that the Definition of Done has been fulfilled and that the customer is getting what he paid for. All of that can be done by using acceptance tests.
faustosiqueira 