We encourage the teams we coach to keep their eye on the ball: Delivering a product that reaches a defined goal and thereby delivers value to its stakeholders in the most efficient, predictable and reliable way possible. This process of delivery frequently includes helping teams improve their internal product elaboration and development practices through the use of Behavior Driven Development (BDD) and Test Driven Development (TDD). And in doing so, it is my observation that there is a bit of confusion over the distinctions between how to focus teams on building the right software, and building the software right.
It seems that one of the key drivers for this confusion has to do with where Acceptance Test Driven Development (ATDD) fits into the development lifecycle. At present, BDD and ATDD both loosely describe a clarification process for iterating or incrementing around acceptance criteria for a given business goal that results in a just-in-time scenario or example-based specification.
What if we clarified things a bit…?
Perhaps we could reduce confusion around “building the right software… right” by redefining the specific meaning and places for BDD and ATDD as follows:
- Formalize the meaning of BDD around the practice of defining the “right” product through goal-oriented behaviors or scenarios.
- Formalize the meaning of ATDD around the practice of building the “right” product by connecting behaviors to automated acceptance tests.
How about the following as a high-level map for “building the right software… right”:
|Start with BDD to clarify the goal, defining behavior-based scenarios that will become acceptance criteria for scenario-oriented user stories|
|Then, (this is the redefinition) use ATDD as the iteration’s goal-oriented roadmap, where the delivery team transforms each behavior into a set of executable steps, or executable acceptance tests, using technologies such as FitNesse, Cucumber, or similar|
|And finally use TDD’s Red-Green-Clean cycles to develop a high quality product with the functionality required to see each step of the executable acceptance tests pass|
This approach clarifies the terms and provides a specific meaning and place in the development lifecycle for BDD, ATDD, and TDD. In my experience the above map has reduced confusion around how to “Build the right software… right”.
Let me know what you think. I’m eager to hear your thoughts and concerns around such a mapping.