Developing software is notoriously difficult. Even today, many software projects still fail for various reasons, such as poor communication, insufficient requirements elicitation, or unrealistic goals. There are many important criteria that are critical to the success of software development, but the following two dimensions in particular must be ensured:
1. we build the right software, i.e. the software must correctly address the requirements and provide real added value for the users.
2. we build the software correctly, i.e. the software meets various quality criteria such as maintainability, freedom from errors, efficiency and reliability.
In addition, software projects increasingly have to be implemented in agile and “lean” scenarios, where in some cases all requirements are not yet clear and the business model has yet to be found.
Behavior Driven Development (BDD) is an agile software development methodology that responds to these challenges and changes. It was developed in 2003 by Daniel Terhorst-North as an improvement over Test Driven Development (TDD). In TDD, you write an automated test (also as code) before the actual feature to test that feature. Of course, this test will fail at first because the feature itself is not yet developed (1). Subsequently, one programs just enough code for the test to be successful (3). Afterwards you can clean up and improve the code (3). The advantage here is that you notice immediately if a change causes an error, because in this case the test would fail again. So in the end you have a clean, maintainable and high quality code and a working feature.
BDD adopts the approach, but goes a few steps further. BDD is also called “requirements-driven software development” because it focuses on actual user behavior. Thus, BDD can also be used during requirements elicitation and documentation. An example of joint requirements specification is the “Gherkin” language (this method is also described in the book). BDD thus contributes not only to dimension 2 “We build the software right” but also to dimension 1 “We build the right software” in particular.
Accordingly, there are some advantages of BDD, as the following incomplete list shows:
– promotes joint collaboration between developers, product owners, testers and other stakeholders,
– promotes joint communication and discussion, e.g. through the language “Gherkin”,
– improves code quality, minimizes bugs and increases various criteria such as maintainability and reusability,
– the automated tests and specifications increase the documentation,
– supports the determination of requirements.
– Ensuring the value of features,
– we reduce waste and cost by building only the features that add value.
In return, however, it must be ensured that the entire team is familiar with this method and works with it together. Shared communication and collaboration are critical to BDD’s success. Furthermore, as described above, BDD can play to its strengths especially in agile scenarios.