Better Software - September 2008 - (Page 25) cceptance test-driven development (ATDD) means many things to many people—from “It’s all about testing” to “It has nothing to do with testing,” and from “TDD, ATDD—it’s all the same” to “TDD and ATDD are nothing alike.” Each of these statements describes ATTD from a single perspective, but neither encapsulates the entire meaning. This is often because different people notice different aspects of ATDD depending on where they are coming from. It’s like asking a friend for directions to his favorite bar, but he can’t recall any of the road names so he gives you landmarks, instead (“Turn left at the clocktower”). But ask another friend for directions to the same place, and you’ll get a totally different set of landmarks. It would be no surprise if you got lost along the way. To explain ATDD and its benefits, I’ve retraced my own steps and also the steps of others to give you the most common landmarks, no matter where you’re coming from. A Where Are We Headed? If you aren’t familiar with ATDD, it picks up where user stories leave off. A user story—an artifact resulting from a related practice—is a brief summary of an end-to-end system capability. I say summary because that’s all it is; it is not a specification or a definition. I emphasize end-to-end because one of the most common mistakes is to decompose a problem into “horizontal” user stories (stories that are split by software component) when instead user stories should be written in terms of a “vertical” endto-end capability. ATDD bridges the gap between an idea summarized in a user story and the implementation of that story. It helps elicit the detail behind the idea to make it better understood by both the customer with the idea and the cross-functional development team that will implement it. This process begins when the first acceptance criteria for a user story is outlined. For new teams, acceptance criteria are discussed before iteration planning. For a more practiced team, acceptance criteria might be discussed during iteration planning. A highly experienced team on a well-established project may find it can still be successful when deferring such discussions until the iteration itself. www.StickyMinds.com SEPTEMBER 2008 BETTER SOFTWARE 25 http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.