Take Your Development Process to the Next Level with Behavior Driven Development (BDD)
Today I want to introduce you to another well-known Agile methodology in the software development world called Behavior Driven Development (BDD).
Some weeks ago, in a previous article, I explained what was essentially Domain Driven Design and what were the pains it was trying to solve. I tell you this because BDD is closely related to DDD, and they share some of the reasons why it was born.
As explained in the past article, software organizations in the past used to work using a waterfall approach where stakeholders would define the new features/products to be released and these requirements will be passed along a series of people in the company until it reaches the developer who will be in charge of converting those business requirements into actual code. The problem was that the language used by business people or product people is closely related with money, and how to maximize the income of the company, while programmers are closer to the code and they know their codebase but may lack or differ in the meaning of some concepts about the business.
How can we make business people and other stakeholders understand the same language as programmers and use the same terms? Well, as explained before, ubiquitous language is the solution which consists on creating a shared model and a common language across the company. But once you have the shared model defined, then what? Business people don’t know how code works, what are classes, functions, … so how can you still be talking to these stakeholders and be able to know what your ticket in Jira you will work on will do?
The answer are examples. Product and devs will understand each other through examples and this is part of the definition of BDD.
BDD is a software development methodology that emphasizes collaboration between stakeholders to ensure that the software being developed meets business requirements and behaves as expected.
This definition besides what explained at the beginning of the article already tells us what are the main principles of BDD, which are:
- 👥 Collaboration: It encourages collaboration between stakeholders, including product owners, developers, testers, and business analysts, throughout the development process.
- 🗣️ Ubiquitous language: It promotes the use of a shared, domain-specific language that everyone involved in the project can understand. The goal is clearer communication and alignment.
- 👁️🗨️ Testable examples: It encourages the creation of executable specifications in the form of automated acceptance tests, which serve as living documentation of the system’s behavior.
How can we use BDD for creating tickets in Jira?
One of BDD’s pilar is the definition of the examples in the task to be done. These examples will be defined inside the acceptance criteria of the ticket.
In case you didn’t know, acceptance criteria are the specific conditions that a product must meet to be accepted by a stakeholder.
A way to redact these examples in the acceptance criteria would be to follow as closely as possible the Gherkin Syntax, that is as simple as following this structure:
- GIVEN is the precondition(s), state, parameters relevant to this particular scenario. Basically, setting the scene.
- WHEN is a trigger, or a state change, the thing we’re testing.
- THEN is the expected outcome(s) of the trigger given the context of the preconditions.
By following this syntax, you will be able to convert those acceptance criteria requirements into the developer’s test cases. For example: Imagine you are implementing a login form in your website and you are defining the acceptance criteria of the ticket for creating the login logic. The ticket creator will list examples like:
- Given an unlogged user that is in the login page,
When entering their email and password correctly
Then the user should be successfully authenticated and redirected to the home page. - Given an unlogged user that is in the login page,
When entering their email correctly but with an invalid password,
Then the user should see a message on the screen in red saying “Your email or password is invalid”.
Conclussions
There are many concepts listed in this article and some of them may not be completely explained, but I hope you grasped the idea of it.
Hopefully you liked it and it was useful to you! :) Until the next one! 😃
