Behavior Driven Development: The methodology that connects the three amigos

The main goal of a software company is to deliver a quality product. We cannot perceive quality without a product in the same way that you cannot deliver a product without quality. Under this premise, we understand that quality is not manufactured, but is part of the development process. Over the years, different roles have been established in order to narrow down responsibilities. Reducing to the basics, within a current agile software team we can find three main roles:

• Business – Product owner: Captures the requirements requested by the client (stakeholders).
• Developer: Implements the requirements captured by the business to create the product.
• Quality assurance: Validates that the final product matches the initial specifications.

Once this division, colloquially known as The three amigos, has been established, it is necessary to agree on a common communication channel. It must be taken into account that some business roles do not necessarily have to be technical, while developers and QAs dedicated to test automation are. Somehow, a methodology has to be found that connects these two profiles, the solution is the BDD.

What is BDD?

Behaviour Driven Development is a software methodology that allows us to define and develop the product based on the behaviour of the system. It was born out of the aforementioned need to be able to communicate the business side with development. This agile process is derived from the well-known Test Driven Development (TDD) whose difference lies in the scope: TDD focuses more on the functioning of the code while BDD focuses on behaviour, from the user’s point of view. It should be noted that both methodologies are complementary, we can have a code developed based on TDD with unit tests, whose functionality and test automation have taken into account the scenarios defined in BDD.

A complete iteration of an improvement in an Agile cycle consists of:

1. The PO meets with the stakeholder to obtain the functional requirement.
2. The PO writes the requirement in User Stories format “As a [user], I want [functionality], so that [Benefit]“.
3. A representative of each profile (PO, DEV and QA) meets to refine, estimate and identify scenarios to cover the User Story.
4. Tasks are created with the definition + agreed scenarios.
5. Parallel to point 6: Developers program the described functionality.
6. Parallel to point 5: QA automation automates the described testing scenarios.
7. When points 5 and 6 are completed through a CI/CD process, the code is deployed in an environment where the automatic tests that validate the development are launched.

Source: flatstack.com

During the process, in order for a task to start development, the agreed DoR must always be taken into account. In the BDD methodology, it is possible to add the point of not starting the development and automation until the ticket does not contain all the acceptance criteria covered by scenarios. In the same way, in order to finish a task, the DoD must be fulfilled: Until the build has all unit tests and automated scenarios with an OK execution in the pipeline, the task cannot be considered finished.

Gherkin Language

Gherkin is a Domain Specific Language (DSL) used in the BDD methodology. The format used is a natural language, which allows to understand the description of the behaviour from a non-technical point of view. In this way, the different scenarios related to the use cases written by the Product Owner can be identified, written in Gherkin format and can be interpreted, developed and automated later by any member of the team: Business Profiles, developers or QAs.

The scenarios described in Gherkin have a very concrete syntax that connects the cause-effect concept of human language with the software concept of input-process-output. The Gherkin standard uses characteristic keywords in its steps:

Given – Preconditions necessary to prepare the initial state of the system so that the user can interact.

When – Actions that the user will execute to obtain the desired output.

Then – Validations to be performed to check that the output matches the scenario description.

And – Extension of any keyword from the step described above.

Example of using the Gherkin language for testing a soda machine

Good practices

Although there are no strict rules or technical limitations when writing scenarios, there are podcasts and blogs from Cucumber developers (a tool used for test automation described in Gherkin) where they recommend a series of patterns to make scenarios more understandable: 

• Scenarios have to be short, but with the necessary information. It is recommended not to use more than 5 steps.
• Features, groupings of scenarios, should not exceed 10 scenarios.
• The steps should describe the behaviour of the system, not concrete user actions such as typing or clicking.
• The scenario should verify a specific behaviour and not do several validations at the same time.
• As subject, it is preferable to avoid the first person singular “I” and refer to the end-user in the third person.

In case the scenarios do not meet the standards mentioned above, it should be remembered that the methodology promotes a direct communication between PO-DEV-QA. Therefore, if either party detects a bad definition, it is possible to iterate on the scenario by modifying its steps or dividing the system behaviour into more features, if the requirement initially presented is very extensive.

Conclusion

Thanks to the existence of BDD, it has been possible to establish software development standards that connect all the roles within an Agile team. Often, there is a tendency to isolate some parts of the process believing that they can function independently. An example is the fact of seeing the testing part as something to be done at the back end, when there is already something tangible in the product. This concept is a mistake if we take into account that many bugs that are found in the last part of the process are actually a definition problem, which is done at the beginning. If we take into account the behaviour of the system and all parts of the team are involved in the definition of the use cases, we avoid many communication errors between what our client wants, how it has to be developed and what tests are going to be carried out to validate the quality of the product.