Introduction

In general, BDD (Behaviour-Driven Development) is set of practices that aim to reduce common “wasteful activities” in software development life cycle. Such as:

1. Misunderstood Requirement that leads to Rework: One of the popular cause of delay in project delivery is unclear or incomplete requirements that gets misunderstood by the development team.
2. Reluctance to Refactor Code that leads to Technical Debt: It does take time to look at somebody else code, understand and simplify without changing its behaviour. Sometime development team ends up providing a temporary patch instead of using a better approach that would take longer.
3. Slow Hand-overs that leads to Slow feedback cycles: Hand-over between the teams easily delays the project delivery whether it’s between PO, BA, DEV, QA even business. 

BDD process promotes healthy collaboration and continuous communication that results in better understanding and precise requirements. Real world examples used during Amigo meetings helps in early defect detection and developing useful automation scripts. 

The Three Amigos

In BDD environment, three voices in any project must be heard always as these three bring different set of perspective on board.

1. Business
2. Development
3. Testing

The three work together to discuss product development (before, during and after). One of the focus in these amigo meetings is the Acceptance Criteria. 

Acceptance Criteria

Any amigo can write acceptance criteria but preferably, it should be conscripted by a non-technical person that bring business perspective. This cycle is repeated until each amigo is satisfied that the scenarios accurately describe what is required in a testable manner. The acceptance criteria is written in Gherkin.

Gherkin

Gherkin is a Domain Specific Language for writing acceptance criteria for a user story. It is created to describe behaviour without defining how to implement it. It outlines all the actions that a user must take to perform a task and the result of those actions. For example, a real-world Gherkin example might look like this:

Scenario: User login

  Given user in on the login screen

  And user enters the username

  And user enters the password

  When user clicks submit button

  Then user is logged on

This Given-When-Then is a gherkin structure to write test cases. The can be tested manually or automated by Cucumber.

Cucumber

Cucumber is a BDD tool for collaboration used by programmers for testing other softwares. It can execute gherkin functional test cases written in plain English. It was originally written in Ruby but today it supports variety of different programming languages. 

1. Feature File: Scenarios based on user stories, written in Gherkin text Given, When, Then, And, But
2. Step Definition: Public Functions/Methods of the scenarios mentioned in the Feature file
3. Runner Class: In Cucumber, the execution starts from here

Using Gherkin to write scenarios makes it simple to show the flows that the product needs to have. Feature files help organise those flows into logical chunks. Cucumber scans those chunks and gives a live readout of which piece of software work and which don’t.  

Benefits

There are many benefits but to highlight the top 5:

1. Universally accepted language: It is understandable and easy to communicate by all the members of the team, which reduces misunderstanding
2. Software development meets business requirements: Using the common language the intensive behaviour software development gets happy business user as the requirements are communicated with little complications
3. Lower costs: Improving the quality of development, reduces the costs of maintenance
4. Higher visibility: Using a universal language gives a stronger visibility throughout the project
5. Greater Collaboration: BDD doesn’t just increases but also improves collaborations. It enables everyone involved in the project to easily engage in the product development cycle

References: