BDD - Behaviour Driven Development

Need for BDD:

To understand the need of BDD, let us throw some light on “What in case of Absence of BDD”.

1. Requirement Analyst writes Acceptance Tests to determine if the product is doing right Thing

2. Developer writes Unit Tests to determine if the code is doing things RIGHT

3. Automation test script (using any tool) to cater regression/functional testing

               

Now, we have three different documentation/levels of definitions i.e. with Business, Developer and QA teams respectively for the same Application under development.

- There are high chances that, the gap between "Business requirement", "Development Specification" and "Acceptance Scenarios"

                - This is a big disadvantage, which ends up in more time to deliver a quality product.

BDD unites all the three definitions into ONE, which eventually minimizes the gap between Requirements, Developer & QA.

Advantages of BDD:

ü  Well defined documentation technique, which conveys the requirement to all the stake holders involved in the complete Software Development Life Cycle in a very simple language.

ü  The steps written in BDD could be understood by Business, Requirement Team,  Acceptance Team, Quality Assurance (Manual and Automation) and also to the developers.

BDD Format

                BDD follows a very simple format using simple keywords.

                Keywords like "Given", "When", "Then", "AND".

                                Given - used to define a precondition

                                When - used to define Actual test step

                                Then - used to define Observation (Expected behaviour)
                                And - used to connect two steps (Anywhere)

These keywords can be used to convey the requirement in a very simplified manner to avoid confusions. 


See an example here

The cucumber format can clearly convey the requirement to the entire stake holders, as they are very understandable.

Cucumber format removes the gap between the "Functional Specifiction", "Business Requirement Document", "Acceptance Specifications", etc