Dale Emery, Consultant
On traditional software teams, business analysts define requirements in batches, describe them in huge documents, and sign them over to developers and testers. Developers interpret the requirements one way and start writing code. Testers interpret them another way and start writing test plans. But their interpretations diverge, and neither precisely matches the analysts’ intentions. The mismatches are discovered late in the project, after much damage is done, and when corrections are costly. Dale Emery describes a better approach—Acceptance Test Driven Development (ATDD) in which the whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins. These tests become the team’s shared, precise, agreed definition of “done” for every feature. In this session you will learn about the entire ATDD cycle and practice key techniques for detailing each feature, distilling acceptance criteria into acceptance tests, and checking for shared understanding. You will take home practical ideas for how to gain clarity, alignment, and confidence in your requirements and your product.
When the workshop is completed, the attendees will be able to:
- Translate ambiguous, fuzzy requirement ideas into concrete examples with expectations.
- Assess acceptance criteria for ambiguity, clarity, and precision.
- Assess how well each team member understands the features to be built.
- Express acceptance criteria in a way that the team can use as automated acceptance tests.
- Describe how ATDD helps to create clarity, alignment, and confidence about a project’s goals.
Target Audience: Intermediate
Dale Emery, 2012 Workshop, Abstract
