A Critical Look at BDD

Behavior Driven Development, or BDD for short, is a powerful framework that is often misunderstood or misapplied. It is based on clear communication and precision that can convince even the most skeptical managers. But BDD is more than just a method - it is a tool for creating precise requirements and turning them into code. Andreas shares his experiences with us and ends with valuable tips for application and integration into the team.

“What we also observe in the projects is that the management says ‘I’ve seen that once, it looks easy, so please do Gherkin/BDD now’” - Andreas Döring

Quality is no coincidence, but the result of functioning teams in which everyone can contribute their strengths. That’s why Andreas is committed to test automation and test management. He also supports his Associate IT Consultants in their professional and personal development. He has a degree in computer visualization engineering and has been working in the field of quality assurance since 2003.

Highlights of this episode:

• We wanted to record the episode live on German Testing Day 2023, but a power cut put a spanner in the works
• BDD is a method in which requirements are formulated in such a way that they can be used directly as tests. The whole team works on a common vocabulary
• Andreas sees problems if BDD is only used at the end of the development process instead of from the beginning
• It is important to have a common language in the team and not just do BDD for BDD’s sake
• You should start small with BDD and not try to do everything with it straight away
• Good tools for BDD include Cucumber and Gauge
• It is important that the specialist staff can also handle the tools and are not overwhelmed
• BDD can bring many benefits if it is used consciously and correctly

From misunderstandings to masterpieces: Using BDD correctly

In this episode, I talk to Andreas Döring about the pros and cons of Behavior-Driven Development (BDD) and how it is often misunderstood or misused. Andreas shares insights and tips on how BDD can be used more effectively to improve projects.

The truth about Behavior-Driven Development (BDD)

Behavior-Driven Development is a method that has existed since 2006 and aims to formulate requirements in such a way that they can also be used in testing. The core objective of BDD is to create a common vocabulary between requirements specialists, developers, testers and those who provide the test infrastructure. By creating test cases in a syntax that everyone can read - usually Gherkin - the whole team should work with the same language from the beginning to the end of the development cycle. This method encourages closer collaboration and a deeper understanding of project requirements.

The most common misconceptions about BDD

Despite the clear advantages of BDD, there are often misunderstandings and misapplications in practice. A common problem is the attempt to introduce Gherkin syntax at the end of a project instead of developing it together with the requirements from the beginning. This leads to the actual benefit of BDD - improved communication and shared understanding - being lost. Many teams see BDD merely as a way to write their test cases in a ‘cool’ syntax without recognizing the deeper value of this practice.

The correct implementation of BDD

A successful implementation of BDD requires more than just learning a new syntax. It is about bringing about a real cultural change in the team by integrating every phase of the development process - from requirements elicitation to test automation. This also means that the team agrees on a language and uses it throughout. This also includes accepting the additional work involved in maintaining the automation and infrastructure, as well as an awareness that not every software component needs to be tested with BDD.

BDD in practice: a pragmatic approach

Andreas recommends a pragmatic approach for BDD: Start small with a well-functioning team and formulate requirements in understandable syntax. This can be Given-When-Then or other formats such as Markdown when using Gauge. The key to success is to be willing to experiment and gain experience to find out what works in the specific project environment. This approach will help unlock the true value of BDD and ultimately make projects more effective.

The role of tools in BDD

While tools such as Cucumber or Gauge can be helpful, Andreas emphasizes the importance of using these tools consciously. Choosing the right tool depends heavily on the project and requires careful consideration of the additional effort required for maintenance and integration into existing processes. It is important to understand that tools alone do not guarantee success; it is how the team uses these tools and integrates them into their way of working.

Tips from Andreas

Andreas urges caution when introducing BDD as a panacea for all project problems. A critical look at the use of BDD can help to avoid technical debt and ensure that this method offers real added value. The biggest challenge is to improve communication within the team and ensure that all members are pulling in the same direction. Only then can BDD reach its full potential.