Better Software - September 2008 - (Page 29) zation—getting people other than testers interested or assimilating developers and testers into one team. Landmark 9: It’s More About the Dynamics Than the Artifacts The Agile Manifesto has a pertinent statement: “We value people and interactions over processes and tools” (while there is value in the item on the right, the item on the left is valued more) [4]. ATDD in the context of XP is an example of how “people and interactions” are of great importance. ATDD within XP is first about people talking, sharing, and learning about the needs of the users in small and manageable iterations. The acceptance-test artifacts are a tool to help focus discussions on the detail that matters and capture the outcome in a way that adds enormous value in other ways, such as automated validation. Sending testers or customers an email and asking for the next batch of acceptance tests doesn’t work even half as well as having a conversation. Figure 2 the business-logic tier rather than feeling restricted to an external interface. Landmark 8: Sometimes It Matters What You Do Call It Having tried the avoid-the-word-test approach, I’ve noticed a detrimental side effect. People think it doesn’t involve testing at all, and later it becomes very hard to convince them otherwise. Meanwhile, testing specialists who would otherwise add value get sidelined. In the past, I’ve avoided the problem of ATDD’s being pigeon-holed as “a testing thing” by avoiding the word test, but I’m beginning to wonder if this is much like the “dark side” of the force—quicker, easier, and more seductive. ATDD really is a cross-discipline activity, not dominated by one discipline or the other. Take one main skill area out of the equation and it suffers greatly. The value of representation from across the whole team—including the customer— is, in my experience, greater than the sum of its parts. I’ve worked on teams that embraced the close involvement of testers with the development team for the first time, simply because of their interest in ATDD or because the developers were already “test infected” thanks to TDD. As the team tried to apply ATDD, team members realized that it was about eliciting requirements, driving the team to build the right product, and testing. Whether you call it ATDD or something else depends entirely on which you feel is the priority for your organiwww.StickyMinds.com Landmark 7: Sometimes It Matters What You Don’t Call It Because the words “test” and “testing” are such overloaded terms, people hear them and immediately jump to all sorts of conclusions. I’ve had conversations with people about acceptance test-driven development and a few seconds later they refer back to it. “Yeah, so that acceptance testing stuff … the users do that just before we go live, right?” Well, no, that sort of testing is to get feedback from the customer, which is part of ATDD. Other times, people say, “Right, that stuff where the testers do all that automation?” Again, not quite, because members of the team contribute in different ways depending on their skills not their job titles. The word test and the phrase acceptance test can, in the minds of the uninitiated, camouflage the other dimensions of the process—requirements elicitation and making sure we are building the right product. So, some prefer to call ATDD something else, such as story-driven development, example-driven development, executable-specification-driven development, behavior-driven development, and many more variations on the avoid-theword-test theme. You Will Then Arrive at Your Destination If you’re just learning about ATDD, hopefully these landmarks have helped you see whether ATDD has potential value for you. If it has, then the next step is to learn by doing. Don’t expect to appreciate its subtleties overnight. Don’t try to do it alone; find someone who is experienced to guide you. The roads you’ll take between each of these landmarks, and any new ones you discover, will be different from one organization to the next. Indeed, the order in which you may pass each landmark may differ from one individual to the next. Whichever route you take, remember to take in the scenery along the way by reflecting on your experience as you observe each landmark. Most of all, remember that it’s also meant to be fun, so make sure you enjoy the journey every step of the way. {end} rEfErEncEs: 1] Beck, Kent. Test-Driven Development: By Example. Addison-Wesley, 2002. 2] martinfowler.com/bliki/SpecificationByExample.html 3] Boehm, Barry. Software Engineering Economics. Prentice Hall, 1981. 4] agilemanifesto.org SEPTEMBER 2008 BETTER SOFTWARE 29 http://martinfowler.com/bliki/SpecificationByExample.html http://agilemanifesto.org 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.