BBD is a process designed to help manage and deliver software development projects by improving communication between engineers and business professionals. In this way, the BDD ensures that all development projects are focused on delivering what the business really needs and meeting all user requirements.
Behavior Driven Development is not about testing, although it implies a lot of testing. But testing is not the goal. Similar to TDD (Test Driven Development), BDD is not about testing. It’s about achieving business goals and customer outcomes at the application level.
What is the relationship between BDD and Agile? Well, with BDD you make sure the software works on top of comprehensive application-level documentation and you still get that documentation. Furthermore, Agile has strong roots in eXtreme Programming.
The core idea of behavior-oriented design is that no person or field has the complete answer to anything. Therefore, three friends are needed in order to get good results: business professionals, developers, and testers. Because it’s the back-and-forth between people with different cognitive styles and different perspectives and backgrounds what delivers magic results. This magic that brings you better, easier and more valuable solutions.
Business professionals provide business needs and customer requirements. They are in the best position to decide how desirable a story is compared to others.
Developers are the experts on software and technology opportunities. They are in the best position to gauge how easy or difficult it will be to implement a story.
Testers are indispensable for their ability to almost instinctively detect obstacles and gaps. They will identify edge cases before they cause problems later on.
What are the benefits of the BDD approach?
By adopting behavior-driven development, you can expect these benefits:
- Consider business goals and customer requirements.
- Guidelines for structuring the conversation between the Three Friends.
- Define acceptance criteria before beginning development.
- Avoid effort on features that do not contribute to business objectives.
- Avoid misinterpretations that lead to redoing the work later.
- Ubiquitous language. A domain-specific language that is used everywhere in the software.
- Executable specifications.
- Automated acceptance tests that provide rapid feedback to keep the implementation on track.
- Living specs that never go out of date.
- Automatically generated technical and end-user documentation that never goes out of date either.
Maybe one of the most important advantages is that software development meets the user needs. By focusing on business needs, you get happy users, and that means a happy business, of course. Actually, with BDD, as the name says, you focus on the behavior, which has a stronger impact than the implementation itself.
The BDD Phases
- Discovery.
Here a story is explored in a structured conversation. It has two objectives. One is to ensure that the story will contribute to business results. For example, with the “five whys” method. The other goal is to ensure a shared understanding of what is needed by outlining concrete examples of specific scenarios.
- Formulation.
This is where the examples are reformulated (formulated) in a structured language and converted into executable specifications. These follow the given-when-then pattern.
- Automation.
This is where executable specifications become automated acceptance tests. Using tools like Cucumber is about connecting the tool with the software.
What is Behavior Driven Testing?
Behavior Driven Testing (BDT) is a lesser known process leading to automated acceptance testing. It also promotes collaboration between technical and non-technical people. And it also uses a formalized natural language to write tests that can be easily reviewed and verified by business professionals.
But BDT focuses more on what users do with the software, instead of the acceptance criteria that verify the business logic implementation.
What is the difference between TDD and BDD?
Behavior-driven development and test-driven development are similar and different at the same time. Both employ testing-first approaches, but they are not testing.
BDD is about improving collaboration and communication between developers, testers, and business professionals, for the software to meet both business objectives and customer requirements.
TDD deals with design and specifications at the code level, while BDD focuses on the app and requirements level. TDD focuses on the code level that implements those requirements.
TDD is, or can be used as the implementation phase of BDD. In TDD you can, but don’t have to, use BDD techniques down to the smallest level of abstraction.
BDD does not have a refactoring phase like TDD.
