Behavior-driven development (BDD) is one of the Agile development methods which focuses on designing and developing software based on users’ behavior and the expected outcome of interactions.
This approach helps development teams to focus only on specific and requested behaviors, rather than scenarios that likely will never happen in real usage of an application. This approach can help to avoid excessive coding, unnecessary features and is maximizing the chance of a great user experience.
What Are the Benefits of BDD?
We can list numerous benefits, and each person that worked with this approach can probably make a unique set of benefits.
We will focus on the most common ones. Without a doubt, one of the biggest benefits of BDD is the customer-centered focus. At the end of the day, the end-user (customer) is who uses the final software. It’s not going to be a developer, not the tester either. BDD helps to lean more into the customer perspective rather than technical implementation. This, in turn, can lead to increased customer satisfaction and overall, to better software, and happier users.
The next key benefit is related to the core software development process. BDD narrows the team’s focus to the user’s behavior, so in the long run it can help reduce the amount of work, and the development effectiveness may skyrocket as a result.
Another benefit that we must mention is improved communication between all project stakeholders. As the stories are behavior oriented and expressed in natural language, it is easier for teams to build common understanding around new features.
How to Use BDD?
The implementation of the BDD can vary between teams and organizations, but in general, there are some bullet points that might help to successfully implement BDD.
User stories are created by the 5 Ws (who, what, when, why, where) principle or the if-then scenario. Good user stories are key, in here we need to have all the information to properly understand the behavior of the user
Outcome for every behavior is highlighted; we need to make sure that behavior will lead to the expected result
Scenarios are translated into specific domain language (SDL), such as Gherkin. The language is not difficult to understand, even for non-technical stakeholders. More importantly, scenarios in SDL will make sure that the flow of the behavior is clear
An example scenario might look like this:
Scenario: User withdraws money Given: User is logged in When: User transfers X amount Then: Balance reduced by X amount
Another example could look like this:
Example: First use of the day Given: I last used the app yesterday When: I use the app Then: I am notified about overdue tasks
Right away, we can see numerous advantages in scenarios formulated according to the specific rules. This format is legible for all stakeholders, both technical and non-technical. The functionality of the feature is obvious, scenarios automatically become feature documentation and steps can be directly used by QA for test automation.
What Are the Drawbacks of BDD?
As any development process, BDD have some cons, mostly related with bad implementation, thus the main con is that BDD may be challenging to implemented. Here are some aspects that may go wrong:
Poor Implementation: The Lack of Requirements/Scenarios Based on “Given, When, Then”
Ideally, requirements/scenarios should be provided by the business side (Product Officer/Project Manager/Product Manager). If they are not, then the development teams are creating them by themselves, which is a serious flaw within the process. This is due to the simple fact that if they aren’t written by the business side, then the development team will interpret everything themselves, which could lead to a difference in what the client wanted vs what the client received.
Poor Implementation: Scenarios Are Created After Feature Development
Scenarios should be a starting point for both developers and Quality Assurance professionals, and work ought to be parallelized.
Poor Implementation: Not All Stakeholders Are Interested in Tests/Scenarios Content
BDD draws power from the close cooperation between teams. If even one side is not engaged, we may quickly lose sight of the whole idea and end up with a chaotic process. Because of that, before introducing BDD there should be an extensive team discussion, to clarify expectations, and everybody ‘s place within a process.
Users' Needs May Not Be Properly Identified
Test scenarios may not be properly written, because of one simple reason. It isn’t always easy to identify the needs of customers. Sometimes, they might not even know what the solution could look like. As such, teams have to spend a considerable amount of time understanding the needs of people who they are developing software for.
Overall, Behavior-Driven Design is a great way of structuring work. It can help build better, and more user-friendly software. In most cases, it can reduce time spent on feature development and lead to higher customer satisfaction through the point of focus around the end user.
It’s not the only design pattern, however. There are others as well which could potentially suit your use case better. They include test driven-development, business driven-development, acceptance test-driven development and many others but BDD will suit you best, if you want to have a collaborative, open and cross-functional development process.
360° IT Check is a weekly publication where we bring you the latest and greatest in the world of tech. We cover topics like emerging technologies & frameworks, news about innovative startups, and other topics which affect the world of tech directly or indirectly.