The main objective of a software company is to deliver a quality product. Over the years, different roles have been established in order to limit responsibilities. Reducing it to the basics, within an agile software team today we can find three main roles:

- Business – Product owner: he captures the requirements requested by the client (stakeholders).
- Developer: he implements the requirements captured by the business to create the product.
- QA: he validates that the final product agrees with the initial specifications.
Once this division is established, known colloquially as The Three Amigos, it is necessary to agree on a common communication channel. Keep in mind that some business roles do not 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, and the solution is BDD (see here).

Behavior Driven Development is a software methodology that allows us to define and develop the product based on the behavior of the system. It was born to be able to communicate the business part with development.

This agile process is derived from the well-known Test-Driven Development (TDD) whose difference is in scope: TDD focuses more on the operation of the code while BDD focuses on behavior, from the user's point of view.

It should be stated that both methodologies are absolutely complementary; a code can be developed based on TDD with unit tests, whose test automation and functionalities have taken into account the scenarios defined in BDD.
A whole iteration of an enhancement 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) meet to refine, estimate and identify the 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.

During the process, so that a task can begin to be developed, what is agreed in the DoR must always be taken into account. In the BDD methodology, the point of not starting the development and automation can be added 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 unit tests and automated scenarios have been executed in the pipeline, the task cannot be considered finished.

Gherkin language
Gherkin´s format is typical of natural language, which makes it possible to understand the description of the behavior 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 later interpreted, developed and automated by any member of the team: business profiles, developers or QAs.

The Gherkin standard uses a few characteristic keywords in its steps:
- Given – Preconditions needed to formulate the initial system state for the user to interact.
- When – Actions to be executed by the user to obtain the desired output.
- Then – Validations that will be performed to verify that the output matches the description of the scenario.
- And – Extension of any keyword of the step described above.
Example of the use of the Gherkin language for the testing of a soda machine

Scenario: Buying a soft drink. Given the machine is on, the user selects the number of the desired product. Then the machine delivers the selected product

Good practices
Although there are no strict rules or technical limitations when writing scenarios, there are podcasts and blogs by Cucumber developers (a tool used for automating tests described in Gherkin) where they recommend a series of patterns so that scenarios be more understandable:

- The scenarios have to be short, but with the necessary information.
- The features, groups of scenarios, must not exceed 10 scenarios.
- The steps must describe the behavior of the system, not specific user actions such as typing or clicking.
- The scenario must verify a specific behavior and not do several validations at the same time.
- As a subject, it is preferable to avoid the first person singular “I” and refer to the end user in the third person.
In the event that the scenarios do not meet the aforementioned standards, it must be remembered that the methodology promotes direct communication between PO-DEV-QA.

Therefore, if any of the parties detects a bad definition, the scenario can be iterated on by modifying its steps or dividing the behavior of the system into more features, if the initially presented requirement is very extensive.