BDD allows technical and business teams to reach own goals while working together and using a language understood by all. Learn how to implement it.
If you follow the latest trends in software development, you may have heard of BDD. Standing for Behaviour Driven Development, BDD is an agile software development process that greatly improves interaction between the technical and non-technical stakeholders in a project.
Top benefits of BDD include:
BDD instigates collaboration between software developers, testers, project managers and business team, smoothing global engagement throughout the development cycle.
BDD makes use of a natural language that non-programmers can perceive, avoiding misunderstandings and making it easier for everyone to follow project’s progression.
# Business value
BDD focuses on business value and needs. Developers set priorities with the client and therefore have a better understanding of their needs. As development is based on value, the number of useless features drops down.
# Self-confident developers
Teams using BDD are usually much more self-confident in their work. Joint collaboration increases developer’s confidence in the quality of their code and allows a better predictability of their work.
# Lower cost
Improving code quality allows to reduce maintenance costs and minimize project risks.
The life cycle of a story in BDD
A regular BDD process can be divided into 4 phases:
Although it may seem simple, this process can be complex and repeated over and over again throughout the lifecycle of a project.
In the definition phase, we must identify the functionalities within the requirement we want to implement. This identification must be made taking into account value for business and expected results. These same results set the basis for business value and the whole flow of activities at their source has to be identified and detailed with examples.
To do this, we have to start not from the beginning, but from the end of the process. We work from front to back, starting from the expected results and outputs and identifying the necessary functionalities to obtain them.
Thus, the sub-phases of this phase can be divided into:
1. Define the functionalities (or epic stories) in terms of business value and expected results
2. Understand the results that reflect business value
3. Define and exploit all flows that give rise to results
4. Explore and detail each of the business rules associated with the processes from which the flows are derived
– Exemplify each of the processes and business rules
Both phases are typically defined by elements of a tri-party team:
1. Business representative
2. Development representative
3. Testing representative
The purpose is to analyze the functionalities, flows, and cases defined in the definition phase in order to understand in depth the business rules involved in the initial client request, such as their acceptance criteria.
Define – Phase 1
Define the functionalities (or epic stories) in terms of business value and expected results
BDD is organized first around high-level features. Although it sometimes seems redundant, they should define well what their value to the business is, so that the teams that work on them understand the reason for their existence and what their value is in the overall context of the application and business.
Understand the results that reflect the value for business
Dan North describes BDD as an “in-out” system. This is because BDD advises to look at the results first and only after to the inputs needed to achieve them.
In the previous password recovery example, the goal is clear. The user has a new password available that allows him to access the system. But what does the client get? An email with a new password or a link that allows you to set a new password for yourself?
Define and exploit all flows that give rise to results
Depending on the expected result, the entire flow of tasks that are at the source may be different. In the previous case, if the client receives a new password in the email, there is a certain flow that has to be implemented. But if you get a link, the flow is different. At this stage, the results should be clear and a description of high-level flows and processes is usually done.
A definition of high-level flows and processes may look like the example below:
Explore and detail each of the business rules associated with the processes from which the flows are derived
Each process of the backflow can lead to a deeper analysis and discussion among stakeholders. This analysis by all parties leads to a greater perception of the details involved in each task, including the perception of details that were not previously considered.
For each activity defined in the flow, the expected scope, alternative flows, limit cases and acceptable boundaries are defined.
From the previous example, defining cases for one of the flow activities:
In projects that work under scrum methodology, each of these activities can give rise to a “User story”. A “User Story” represents a part of the functionality and should be able to be implemented in the duration of the sprint. They are usually sized to take no more than a day or two, but we cannot assume this as an absolute rule.
Still, in the scope of Scrum, an “Epic Story” can be considered as a BDD feature. In this case, an “Epic Story” is not defined in terms of the time it takes to be implemented but in terms of the value for the business.
Define – Phase 2
Exemplify each of the business processes and rules:
In this sub-phase, examples are defined for each of the processes and business rules. The examples should try to be in sufficient numbers so that there is no ambiguity about what they represent. Eliminating ambiguity also minimizes the risk that the end product doesn’t meet Business Area’s needs.
In larger organizations, teams sometimes do not have extensive access to business area representatives. In these cases, the exemplification tasks start with an analysis made by the Development and Testing teams, and examples are later validated by the business representatives. This practice, however, shortens one of the fundamental basis of BDD, which is involvement from three parts.
Often too, this exemplification phase is left for a sprint story. Development teams start working on what will be the foundations of the application, relying only on the processes and information flows already defined.
At this stage, the team normally expresses the acceptance criteria in the form of “action-verification-condition”, ie
Given <a precondition>
When <a certain action is performed>
Then <there is an expected result that is the result of this action>
Although this is a way that eliminates many ambiguities, at this stage it is not mandatory to use the nomenclature “Gherkin”. The team can define the business rules and their examples using a less formal form in terms of syntax.
In essence, what is wanted is the clear definition of all the business rules associated with each of the process stages.
The result of this model process is a set of information that can serve as acceptance criteria on the one hand, but also limits or eliminates any ambiguities that may exist in the perception of requirements when they are defined at a higher level.
The register phase consists of passing the requirements identified in the analysis phase to a more formal Gherkin structure:
Since this formalization according to the Gherkin syntax takes some time, the tri team does not need to be present in full. It is normal that this phase is carried out by the element of the testing team.
Once the transition to a Gherkin structure “Given that-> When -> Then” is complete, it is reviewed by the other members of the team, with a more or less formal acceptance of these functional requirements.
Having the scenarios described, we have the conditions for them to be automated. Typically, this automation is performed by testing team members who may have a more technical profile but might also be performed by development team members, especially those who are accustomed to or want to introduce Test Driven Development practices in the project.
The automation of test scenarios can and should be done within the sprint, but it implies that development finalizes their stories in time for the testing team to automate them. This presupposes an effective control that execution is following the planning so that there are no delays in implementation and testers have enough time to automate and execute the tests.
You can consider delivery as the completion of automation, where automated scenarios can go into a test pool. But if we consider that a story does not end as long as the acceptance criteria are not satisfied, then delivery is always associated with acceptance of the implementation made, i.e. at the closure of the story.
When it is closed, automated testing joins the already existing set of automated tests, thus increasing the set of regression tests that can be run.
And off we go to the next sprint to repeat it all over again!