The Business and Test Analysts' Guide to Acceptance Test Driven Development

On traditional software teams, business analysts define requirements in batches, describe them in big documents, and deliver them to developers and testers. Developers interpret the requirements and start writing code while testers interpret them and start writing tests. Almost always the interpretations differ, and neither precisely matches the analysts’ intentions. The mismatches are often discovered late in the project, after much effort has been expended and when corrections are most costly. Dale Emery describes a better approach-Acceptance Test Driven Development (ATDD)-in which the entire team collaborates to create acceptance tests as a key part of the requirements definition process. These tests become the team’s shared, precise definition of what each requirement means to the team members and customers. Dale describes the ATDD cycle, including detailing each story, distilling acceptance criteria into acceptance tests, automating these tests, and demonstrating the resulting story to business stakeholders. Take home practical ideas for gaining clarity, alignment, and confidence in your requirements, your product, and your requirements process.