Automation insights and productivity tips from LEAPWORK.

All Posts

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.

Traditional Development Process

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.

Behavior Driven Development Process

 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.


Download BDD Whitepaper

Lucia Cavero-Baptista
Lucia Cavero-Baptista
Content Marketing Manager

Related Posts

Test Automation and RPA Tools: What's the Difference?

If you’re using test automation and recently began looking into RPA, or if you are new to test automation but using RPA as a means to achieve efficient operations, you might at some point have wondered what the difference is between the two often interchanged terms, as well as if you can use the same tool for both.

[WHITEPAPER] Automating Workday® with LEAPWORK

An increasing number of companies are seeing the benefits of RPA in Workday®. Unfortunately, developing RPA functions is costly and time-consuming, requiring new personnel with specialized and expensive skills. So how can a company get the most out of automation without incurring massive implementation and maintenance costs?

Data-Driven Testing With Codeless Selenium

Data is found everywhere. Whether you are testing an application’s functionality with different data parameters or automating the process of moving data from A to B, you have probably realized by now that data is found to be a key component in most automation cases.