What is Behavior-Driven Design?

Behavior-driven development (BDD) is one of the Agile development methods which focuses on designing and developing software based on users’ behavior and the expected outcome of interactions.  

This approach helps development teams to focus only on specific and requested behaviors, rather than scenarios that likely will never happen in real usage of an application. This approach can help to avoid excessive coding, unnecessary features and is maximizing the chance of a great user experience.

What Are the Benefits of BDD?

We can list numerous benefits, and each person that worked with this approach can probably make a unique set of benefits.  

We will focus on the most common ones. Without a doubt, one of the biggest benefits of BDD is the customer-centered focus. At the end of the day, the end-user (customer) is who uses the final software. It’s not going to be a developer, not the tester either. BDD helps to lean more into the customer perspective rather than technical implementation. This, in turn, can lead to increased customer satisfaction and overall, to better software, and happier users.

The next key benefit is related to the core software development process. BDD narrows the team’s focus to the user’s behavior, so in the long run it can help reduce the amount of work, and the development effectiveness may skyrocket as a result.

Another benefit that we must mention is improved communication between all project stakeholders. As the stories are behavior oriented and expressed in natural language, it is easier for teams to build common understanding around new features.  

How to Use BDD?

The implementation of the BDD can vary between teams and organizations, but in general, there are some bullet points that might help to successfully implement BDD.

• User stories are created by the 5 Ws (who, what, when, why, where) principle or the if-then scenario. Good user stories are key, in here we need to have all the information to properly understand the behavior of the user
• Outcome for every behavior is highlighted; we need to make sure that behavior will lead to the expected result
• Scenarios are translated into specific domain language (SDL), such as Gherkin. The language is not difficult to understand, even for non-technical stakeholders. More importantly, scenarios in SDL will make sure that the flow of the behavior is clear

An example scenario might look like this:

Scenario: User withdraws money
Given: User is logged in
When: User transfers X amount
Then: Balance reduced by X amount

Another example could look like this:

Example: First use of the day
Given: I last used the app yesterday
When: I use the app
Then: I am notified about overdue tasks

Right away, we can see numerous advantages in scenarios formulated according to the specific rules. This format is legible for all stakeholders, both technical and non-technical. The functionality of the feature is obvious, scenarios automatically become feature documentation and steps can be directly used by QA for test automation.

What Are the Drawbacks of BDD?

As any development process, BDD have some cons, mostly related with bad implementation, thus the main con is that BDD may be challenging to implemented. Here are some aspects that may go wrong:

Poor Implementation: The Lack of Requirements/Scenarios Based on “Given, When, Then”

Ideally, requirements/scenarios should be provided by the business side (Product Officer/Project Manager/Product Manager). If they are not, then the development teams are creating them by themselves, which is a serious flaw within the process. This is due to the simple fact that if they aren’t written by the business side, then the development team will interpret everything themselves, which could lead to a difference in what the client wanted vs what the client received.

Poor Implementation: Scenarios Are Created After Feature Development

Scenarios should be a starting point for both developers and Quality Assurance professionals, and work ought to be parallelized.

Poor Implementation: Not All Stakeholders Are Interested in Tests/Scenarios Content

BDD draws power from the close cooperation between teams. If even one side is not engaged, we may quickly lose sight of the whole idea and end up with a chaotic process. Because of that, before introducing BDD there should be an extensive team discussion, to clarify expectations, and everybody ‘s place within a process.

Users' Needs May Not Be Properly Identified

Test scenarios may not be properly written, because of one simple reason. It isn’t always easy to identify the needs of customers. Sometimes, they might not even know what the solution could look like. As such, teams have to spend a considerable amount of time understanding the needs of people who they are developing software for.

Conclusion

Overall, Behavior-Driven Design is a great way of structuring work. It can help build better, and more user-friendly software. In most cases, it can reduce time spent on feature development and lead to higher customer satisfaction through the point of focus around the end user.  

It’s not the only design pattern, however. There are others as well which could potentially suit your use case better. They include test driven-development, business driven-development, acceptance test-driven development and many others but BDD will suit you best, if you want to have a collaborative, open and cross-functional development process.

‍