Traditional Development vs. Behavior Driven Development (BDD)

Behavior Driven Development (BDD) is no new concept in the software development industry. Still, many companies don’t fully understand the benefits of this framework in the development process. In a world where traditional development methodologies have excluded team members in silos, BDD serves as a collaborative force that fosters agile development.

Traditionally, in the software development industry, you would find teams with no shared understanding of what was actually being built. Unfortunately, this still happens nowadays to those who haven’t shifted to agile development yet. The reason is that team members that work in silos have a broken collaborative working culture.

A traditional development process would go as follows:

1. Relevant stakeholders tell product owners their business needs.
2. Product owners write requirements based on those business needs.
3. Developers and testers (independently) translate those requirements into code and test cases.

The problem with this process is that there’s no shared understanding of what is actually being built; meaning that developers, for example, might misunderstand the requirements and build something different than what was expected from them. The reason why they’re not communicating together is because they’re working in silos. Therefore, the result is a finished product that doesn’t match the stakeholders’ business needs.

A solution to this problem is BDD, which promotes collaboration between all team members; product owners, developers, testers and stakeholders.

A BDD process would look more like this:

1. Relevant stakeholders tell product owners their business needs.
2. Product owners then create a collaborative space with developers and testers so that they can talk about what they’re going to develop together.
3. During this phase they collaborate around requirements and define them as English format scenarios.
4. Developers write code based on these scenarios and testers create automated test cases that report back against these scenarios.

This methodology allows the team to focus on the behavior of a system instead of the implementation features, thus driving value in the final product. By specifying these terms in advance, we make sure that developers won’t have to revisit work because requirements were misunderstood.

A way of writing the end-user’s behavior is to create a shared language for your team that everyone understands, such as English-like constructs. BDD’s test scenarios are written using regular expressions – DSL – to map steps in a feature file into concrete actions. A scenario would be written using the following format:

• Given [initial context]
• When [event occurs]
• Then [ensure outcome]
• And/But [more outcomes if applicable]

By using plain language, everyone involved in software development can easily understand what’s going on and is able to contribute to the creation of behavior scenarios. Thanks to this collaborative environment, development becomes more efficient and error-free; in other words, more agile.

In sum, BDD is an agile methodology to software development that relies on a ubiquitous language to describe user-behavior through clearly understood requirements that lead to successful software development. It is a methodology that promotes collaboration between product owners, developers, testers and other stakeholders.

BDD places a lot of emphasis on team collaboration and cross-functional workflows. Leapwork Automation Platform leverages on these through a unique visual language that allows to apply a BDD methodology in testing. See it for yourself.