Building the right software…right, It’s easy…RIGHT?
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”:
|
(1) |
Start with BDD to clarify the goal, defining behavior-based scenarios that will become acceptance criteria for scenario-oriented user stories |
|
(2) |
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 |
|
(3) |
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.
Comments (3)
janvanderhaegen
Hey Isaac,
personally I feel you’re cutting BDD short by only describing the agile methodology, ignoring the technical aspect, and then re-complementing with ATDD and TDD.
By Dan North’s definition of BDD (“BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”) you’ll notice that BDD in fact includes ATDD. (“High-automation”, “tested software”). Your definition seems minimize BDD to the outside-in pull-based agile methodology.
I feel there would be less confusion by stating that ATDD is one of the cycles of BDD.
Continuing down this road, the executable steps that you describe in ATDD are in fact unit tests (from a technical POV). Each step should be generating multiple unit tests by the way, for example a unit test on the domain model layer, a unit test on the integration layer, a unit test on the coded UI layer, … TDD’s Red-Green-Clean cycles are the obvious way to then go and implement the software… (This is the “multi-level / multiple-scale” aspect of BDD)
I feel there would be less confusion by stating that TDD is the next cycle of BDD.
Eventually the point that I’m trying to make is that BDD is the whole thing: describing business problems from the POV of the stakeholders, write down these goals into scenarios (specification-by-example), make automated tests (multiple, on various scales) to verify each step, then Red-Green-Clean until tests prove the software (not just the code) works, do hallway testing / review meetings / …, deliver the software.
Many business-people cut BDD short of the technical aspect, just as many developers cut BDD short of the interaction/discussion cycle. (“Just give me the specs so I can write this code”…)
Take care,
Jan
Hey Jan,
Thank you for taking the time to read the post and also for your thoughtful reply. I completely agree with your perspective on BDD being the whole thing–an iterative communication process for developing and delivering the right product.
Even still, while BDD is the whole thing, it may or may not include ATDD in the same way that ATDD may or may not include TDD. For instance, some teams use BDD to derive behaviors from high-level product goals without using ATDD to distill those behaviors (acceptance criteria) into a set of automated acceptance tests. Likewise, some teams distill their acceptance criteria and then develop the solution without using TDD.
So, while there are other approaches to “building the right software, right”, I think we benefit from having a map that formally includes BDD with ATDD with TDD. Please let me know what you think!
Sincerely,
-Isaac