Book demo
Start trial
Book demo
Start trial

The LEAP

Automation insights and productivity tips from LEAPWORK.

All Posts

How Does Behavior-Driven Development (BDD) Support Agile Development?

Behavior-Driven Development (BDD) was carefully developed to support agile development in the software industry. This is because agile cannot be fully deployed if the testing process still follows a traditional methodology.

In order to explain the real purpose of this methodology, and how it came to be, we first must understand what it’s not. BDD was built as an alternative to the traditional waterfall method in order to better support agile development.

In the waterfall model, testing starts once the development work is completed. This structured and rigid approach doesn’t allow for alterations or changes until the testing phase has finalized, which slows down the development process considerably.

When we look at the teams who are currently using BDD, most of them have gone through a similar process. Their organization decides that they need to go to market faster and, therefore, accelerate releases. After some consideration, they decide to go agile through the means of sprints, scrum, or the like.

Then, after some time, they realize that testing has become the bottleneck of their agile efforts as QA struggles to keep up with this accelerated pace. Therefore, they finally decide to seek continuous testing through test automation.

Even though this decision will most probably improve the current state of the project in some way or another, there are two key issues that will arise throughout this last agile implementation to the software development process:

  1. How aligned is development and QA at this development speed?
  2. How can they make sure that they are building what the customer wants?

The common denominator in the answers to these questions is collaboration; and BDD facilitates just that.

What is BDD?

BDD is a set of practices that make interactions possible between individuals in a team. Through conversations, examples and automated tests, the team is able to discover, and then implement, the desired behavior of a given software.

It is based on the same principle as the ‘three amigos’, where business, development and QA collaborate to define what to do, how to do it and how to know if it’s been done correctly.

  • Business stakeholder: What problem do we want to solve?
  • Developer: How do we build a solution that solves this problem?
  • Test manager: What could possibly happen that prevents this?

 In BDD, this conversation is utilized to write test scenarios in English-like constructs that clearly describe the end-user’s behavior. Meaning that if there are other relevant stakeholders apart from the “three amigos”, they can – and should – be involved in the conversations.

By doing so, all relevant stakeholders in the software development process have a clear idea of what it is that they are trying to build. Thanks to this, they are able to identify any possible misunderstandings and confusion early in the process, thus enabling each participant to successfully perform their respective tasks.

All in all, BDD offers a methodology that allows teams to become fully agile in the software development process. It extends and builds on standard agile practices – such as sprint planning, user stories and acceptance criteria – and makes them much more effective.  

It helps teams build the right thing by enabling teams to locate and concentrate on the features that really matter. This, in turn, will reduce rework and time-waste as well as accelerate the flow of value.

What key characteristics of BDD complement your agile efforts?

  • Collaboration through face-to-face conversations: BDD promotes communication between key stakeholders in the software development.
  • Working software is the primary measure of success: BDD gives a platform to all stakeholders to identify any possible misunderstanding and confusion early in the process, helping the team building the right thing.
  • Capture requirements at a high level – lightweight and visual: BDD describes the end-user’s behavior through test-scenarios written in English-like constructs.

We should not forget that conversations in development matter because software is – after all – made by people. When we look at the bigger picture, we realize that testing is not the bottleneck; ignorance and uncertainty are.

There are many ways in which you can combat those; BDD is one.

Download BDD Whitepaper
Lucia Cavero-Baptista
Lucia Cavero-Baptista
Content Marketing Manager

Related Posts

Test Automation of Native Apps on Real Devices

Enterprise mobile apps are mission-critical, but most enterprises have not yet solved the puzzle of how to perform test automation of native iOS and Android apps on real devices. In this blog post, we show how easy it is to do just that with LEAPWORK and BrowserStack’s (https://www.browserstack.com) real device cloud.

Decoding Automation Podcast: #1 'The No-Code Manifesto'

What motivates someone to write a manifesto? And why is it necessary to create one in the world of automation?

How To Use RPA in HR [w/ real-world example]

Even though HR departments are made by people for people, what if I told you that robots can help HR become more human?