What Is (And Is Not) BDD?
IT Tips & Insights: A Softensity Senior QA Engineer discusses common misconceptions about behavior driven development in this two-part series.
By Nicolas Martino, Senior QA Engineer
In the IT business, BDD is becoming more relevant in the development process. But what is it? BDD is behavior driven development, a process in which the entire team focuses on the behavior of the app that is being created.
But since I started to learn more about it, I’ve seen many teams using it in the wrong way. I’ve also noticed a lot of misconceptions about BDD, the biggest of which is that it’s used only for automation testing. Also, that the examples/scenarios that are created are written in a script format instead of a behavior format.
So today I will talk about the first of the most popular misconceptions that teams have about BDD.
BDD Is Only for the QA Team
This is one of the biggest misconceptions because BDD was created to be a process for the entire team to do together in order to understand the different behaviors that the app will have.
The image above exemplifies exactly what I want to say about how the scenarios could be misinterpreted, which would translate into more work for the whole team.
The way to avoid this would be the “Three Amigos” meeting. This is a meeting that is performed before the start and even before the planning, in which the representative of the QA team, the business team, and the developer team will talk about the app and ask questions about how the app works, what behaviors it will have, how it will handle different scenarios, real-life examples, etc.
Some of the processes that can help you take full advantage of the “Three Amigos” meeting are:
- Ask for real-life examples about the app
- Use example mapping with real-world examples
- Use feature mapping with real-world examples
- Work with tables
- Slice large features into smaller ones
After the “Three Amigos” meeting, most of the time the QA representative and the Dev representative will meet again and start to write the different scenarios and examples in a way that makes it easier to code the app, and to use for automated cases. The most commonly used language for this step is the one called “Gherkin,” which uses the “Given,” “When,” “Then.” But I’ll talk about this and related misconceptions in the next post.
See you next time, and happy testing.
Hi There, I’m Nicolas, I’m 34 years old and I have been a Tester for more than 13 years. I started as a Manual Tester and then changed to Test Automation Engineer. I have a lot of experience with different code languages such as Java, C#, or JS, as well as using many different automation technologies such as Selenium WebDriver, Appium, or Protractor. Right now I’m learning more about how to automate the entire team to deliver more quality products.