Central to the world of software development is the need for clear communication and shared understanding. However, this is often a challenge, especially in complex projects with multiple stakeholders and numerous functionalities.
Take this fun cartoon as an example. It perfectly depicts how communication works in most projects. In the world of software development, it is all too common for a customer to want a swing but get a chair and get a bill for a roller coaster. This is where Behavior-Driven Development (BDD) comes in, a philosophy that not only accelerates software development, but also improves communication and collaboration between teams and customers.
The five steps of BDD and how Lemon implements it:
1) Describing behavior
With BDD, everything starts with describing the desired behavior of the software. By default at Lemon, we start by building a roadmap of all the behaviors within the app. This goes from the login at the beginning to all the actions the user wants to do within the app itself.
2) Write step definitions
Before we do anything, we have a meeting with all the people involved in the project, the Three Amigos. Within Lemon, we involve the developer, customer and product architect in this meeting. There we discuss the previously created actions and turn them into workable use cases to create a shared understanding and determine acceptance criteria.
Let's take "login" from the previous step as an example. There are multiple ways for a user to log in, and depending on what kind of user is logging in, the behavior may be different. For example, it may turn out that a user with an administrator role needs to go to a different page after logging in. These use cases are translated into scenarios that contain steps a user must take to perform the action. These are bundled into a feature file. Within Lemon, we use Gherkin to write these scenarios, a language with a lot of support for testing in almost all programming languages.
The scenario for the login example could look something like this;
There is an art to writing these scenarios, for which the BRIEF principle is used.
- BusinessLanguage: Scenarios should be formulated with words that come directly from the business domain. This allows all team members, even those who are not technically savvy, to easily understand the scenarios. Avoiding jargon and technical terminology is essential to promote business team engagement.
- Realdata: Function files should contain real possible data rather than random text such as lorum ipsum. This ensures that scenarios are realistic and can be better understood by all stakeholders. Using real data also helps identify potential problems or edge cases that might otherwise be overlooked.
- Intentionrevealing: Scenarios should reveal the intention of what the actors in the scenario are trying to achieve, rather than focusing on the mechanism of how they are going to achieve it. By emphasizing the "what" rather than the "how," scenarios can better illustrate the intended functionality and avoid misunderstandings.
- Essential: Scenarios should focus on illustrating one line or functionality. Elements that do not directly contribute to this goal should be removed to maintain focus and keep scenarios clear and concise. The goal is to clarify the desired behavior of the application without being distracted by unnecessary details.
- Focused: Each scenario should be focused on illustrating one specific rule or behavior of the application. This provides a clear and structured approach, with each scenario corresponding one-to-one to a specific feature or functionality of the application. In this way, teams can focus on understanding and implementing one behavior at a time, optimizing development efforts.
And as a bonus, you can think of BRIEF itself as a rule. Keep your scenarios as concise as possible.
Once all these scenarios are created, we validate them again in a Three amigos meeting. This ensures that each stakeholder understands them and gives the opportunity to correct any errors and misconceptions.
3) Execution and failure
Once the feature file is discussed and reviewed, developers can work with it and begin development. The feature file is translated into tests, with each step of a scenario representing a test.
In the previous step, we used Gherkin as the language for the feature file. This allows us at Lemon to easily use Cucumber acts as a tool for linking tests to individual steps contained in the Gherkin file.
At Lemon, we use test-driven development. Take our admin login example: if we were to implement functionality first and then test, there is a good chance that the test, especially one that checks the current page, would consistently indicate success. To avoid this problem, at Lemon we write Cucumber tests first before implementing functionality. This approach helps reduce the likelihood of misleading test results.
4) Write code to get through the step
Now that the tests are written, we can write the code to make them succeed. For example, make sure the user can log in and admins end up on their own screen.
5) Perform and succeed
Finally, the test cases are run again and they should now all pass, indicating that the software is functioning correctly according to specifications. Thanks to our use of Cucumber, we can export these results into a nice report.
Stakeholder benefits:
BDD provides benefits for all stakeholders within a project. BDD creates a more streamlined development process withliving documentation, fewer misunderstandings and better collaboration between team members and stakeholders. In addition, stakeholders individually derive a number of benefits from BDD;
Product Architect / Functional Analyst:
- Maintains status of projects through living documentation.
- Has overview of all functions.
- Improved communication with all stakeholders through the use of Ubiquitous language.
- Remains continually involved through Three Amigos
- More control over what automated tests are written for.
- Early validation of acceptance criteria.
- Reduces manual testing and provides faster feedback on software quality.
-
Developer
Better understanding of expectations.
Shared understanding of requirements.
Early feedback.
Easily identify what breaks when developing new features.
BDD tests can serve as documentation, making onboarding easier.
Increased development efficiency.
Automated test cases.
BDD test cases: readable, verified, discussed.
Customer:
Can correct misunderstandings more easily.
Retains participation in the project.
Clearly defined functionality with faster validation => fewer errors and repair costs.
Transparency in the development process through living documentation => has overview of everything that is happening.
Sales:
Can state what has been done in a project.
Has documentation about a project that they can understand.
Can sell these benefits to potential customers.
Reports serve as easy-to-share examples of how it works.
In a nutshell, Behavior-Driven Development provides a structured and collaborative approach to software development that not only improves the quality and efficiency of the development process, but also improves communication and engagement of all stakeholders.
.svg)
.svg)
.png)
.png)