Quality of software should be taken care of from the very beginning of a project. That’s the core of Behavior-Driven Development!

Quality is not something that you add when the project is almost done. Like, let’s add 5 sugar spoons of quality, stir it up and pass it to users. You can compare that to adding a Quality Assurance team to a project when most of the software features have already been developed and changing them would require too much time and effort. Behavior-Driven Development can help you find bugs by involving the QA team and their observation power in the initial state of the project.

What is Behavior-Driven Development

Behavior-Driven Development is an agile software development process that promotes collaboration between developers, software testers (QA) and the non-technical, business side in a software development process. Those three parties, in the BDD process, are usually referred to as The Three Amigos. Their goal is to, by means of collaboration, eliminate all the possible errors in the software – even before any line of code is written.

How do they do it?

BDD has emerged from Test-Driven Development, which is also a test-first approach, whose tests aim to check the application’s functionality (unlike BDD whose tests aim to test the actual behavior of the system from a user’s perspective).

In order to be able to test the behavior of the system, Three Amigos get together, brainstorm and write potential behavior scenarios for testing. The scenarios should be written in plain language that everyone on the project can easily write and understand – both technical and non-technical people, from clients to testers. Furthermore, to avoid misunderstandings, but also to improve quality and avoid missed deadlines, The Three Amigos meet regularly to discuss how the product will be developed.

How each of the Three Amigos contribute to writing scenarios?

1. Business (Business Analysts, Product Owner, Project Manager) – answers to questions like “what problem must be solved”. They provide requirements and they don’t need to have technical knowledge.
2. Development – answers to questions like “how will the solution be implemented”. They are technical experts and they build the software.
3. Testing (Quality Assurance) – verifies that the software works correctly. They need to have some technical knowledge, but not as much as Development.

Behavior-Driven Development Process

At the beginning of the BDD process, the product owner gets as much information as possible about users and their needs. Then The Three Amigos get together and work out the requirements and write structured scenarios in plain English language that anyone can understand.

Written scenarios keep developers focused on delivering precisely what the product owner wants, because the scenarios act like their acceptance criteria and a lodestar during the development process.

For testers, those scenarios can be a base for writing test cases and automated test scripts. This speeds up the testing process and helps achieve greater test coverage.

Product owner shows the scenarios to the user, client or other stakeholders – as they can easily understand what’s written, they can confirm that these scenarios describe exactly what the software should do, or not.

Scenarios written in plain language guarantee that all the people on project, at any point in time, clearly understand what are the requirements and how the software should behave. This helps to avoid any misunderstandings and games of broken telephones. Another outcome is that you have structured and executable documentation, which is very helpful when you need to bring new people to the project or when two different teams build software and do the maintenance.

Here is one made up example – scenario for a feature “Mobile Account top up with credit card” written in plain language called Gherkin.

Feature: Mobile Account top up with credit card
In order to top up my mobile account with credit card
As a mobile user
I need to have a valid credit card with sufficient funds

Scenario: Credit card account has sufficient funds

Given the credit card has sufficient funds
And the card is valid
And the mobile account balance is 5€
And the user enters a valid mobile phone number on the top up page
When the user confirms mobile phone number
And chooses 15€ top up
And enters the correct credit card details
Then the user should see a successful top up message
And the mobile account balance should be 20€

After reading this scenario and the scenario steps, you can easily understand how the feature should behave when the user has sufficient funds on their credit card account. In order to prevent bugs from happening, our goal is to cover as many scenarios as possible. Also, we can use them afterwards to verify that the feature works correctly.

So, for this feature we could also describe scenarios like “user doesn’t have enough money on his account”, “user doesn’t have a valid credit card” or “user’s sim card is inactive”…and many others.

BDD solves the problem of QA becoming agile..

Some companies are still struggling to include a QA team in their agile process, and even though they are doing agile, QA starts with testing and finding bugs at the very end of the software development process. This is usually an expensive and more time-consuming approach. And it is not always just the bugs – sometimes the project team wanders off from the real software objective trying to impress the clients. It’s like building a spaceship for a user that just wanted a Vespa to go to work. These kinds of problems can be recognized by writing behavior scenarios, which is where the QA role comes into play. With their ability to put themselves into users’ perspective, they can advise different behavior scenarios in order to make sure that the project goes in the right direction and to eliminate the “what if?” kinds of questions as early as possible.

Challenges

As BDD is based on collaboration, one of the biggest challenges is that it requires a high level of business engagement and it is usually hard to get business parties to start to collaborate on this level.

BDD pairs nicely with agile software development, but it’s really hard to use it with waterfall – and that is one of its downsides. Another one is that you need to have all of your project people in one place and always on the same page, so it is nearly impossible to outsource, for example, backend developers or a QA team.

Conclusion

If you are doing agile in your software development process, Behavior-Driven Development is an add-on that is worth considering. It could save you trouble finding high-severity bugs during the development process or even after the coding is finished. BDD increases the quality of the software and steers your project in the right direction. Furthermore, it makes it easier to include your QA team in every sprint of the agile process.

If you want to learn more about BDD, check out some of these articles:

The behavior driven three amigos
BDD 101: writing good Gherkin
Writing BDD test scenarios
Behavior Driven Development
Why should designers care about behavior driven development

Behaviour Driven Development – BDD
BDD in action

We’re available for partnerships and open for new projects.
If you have an idea you’d like to discuss, share it with our team!