Later that afternoon, in Elisabeth Hendrickson’s workshop on “Beginning with the End in Mind: Acceptance Test-Driven Development (ATDD) in Practice”, she talked about what ATDD is, the ATDD Cycle (Discuss, Distill, Develop, Deliver) and why you would use ATDD. Unlike TDD which is a design practice, ATDD is a shared understanding of what the user story is about. A user story is a placeholder for a conversation to take place on what it is we’re supposed to build. ATDD captures this in examples with expectations creating executable specifications. This means that there is a one-stop-shop for requirements, which is great because previously we needed a traceability matrix to tell us which documents to update whenever there is a change. With ATDD, the requirements are expressed in acceptance tests. If there is a change in requirements, we update the tests directly and we can easily see how close to done we are at any given point in time by looking at what acceptance tests have been passed and what is left to do.
With ATDD, we no longer have to argue about whether an issue is a bug or not – if it violates the letter or spirit of the product owner’s expectations for the story then it is a bug. Other benefits of ATDD highlighted by Elisabeth included the ability to clarify intent & drive out ambiguity early (while the user story is being defined); high visibility of progress (how done are we); ability to leverage the artefacts for multiple purposes (e.g. use as requirements and tests); and ability to automate the regression checks.
It was a great workshop and good to see ATDD in practice with an actual user story and taking it through the process.
Posted by Donna Chin