Agile Frameworks #8 - BDD

Behavioral Driven Development incorporates concepts from Test-Driven Development and domain-driven design.

Test-Driven Development is an approach to software development where developers create tests first and then write the code to pass the tests. Behavior-Driven Development is considered an evolution in the thinking behind Test-Driven Development and it was developed by Dan North as a response to the issues he encountered while working with Test-Driven Development. Some of those issues were, for example,

1. Where to start in the process of testing
2. What to test and what not to test
3. How much to test in one go
4. What to call the tests
5. How to understand why a test fails

Behavior-Driven Development aims to improve a team's ability to deliver prioritized, verifiable, business value using a shared language known as ubiquitous language. So BDD concentrates on building a simulation of the problem domain, and then attempts to minimize misunderstandings between users of the software and the developers by having this common vocabulary. That common vocabulary is what we call a ubiquitous language. 

Testing in Agile

Agile methods avoid the inefficiencies and overheads in traditional testing approaches by introducing the concepts like test automation, collaborative testing, full life cycle testing, reduced overheads, and minimum documentation.

1. Test Driven Development (TDD) — Tests are written before code and passing the tests is the critical driver of development.
2. Acceptance Test Driven Development (ATDD) — Team members with different perspectives (customer, business analyst, tester, developer) collaborate and write acceptance tests in advance of implementing the corresponding functionality.
3. Behavior Driven Development (BDD) — Tests are written in a non-technical language that everyone can understand (e.g. a domain-specific language like Gherkin). BDD combines the principles of TDD and ATDD and forms an approach for building a shared understanding on what kind of software to build by discussing examples.

Behavior Driven Development (BDD)

In Agile environments, BDD plays a vital role because it strongly encourages the use of Agile methodologies during the development and testing. BDD brings customers, end-users, BAs, QAs, and SEs of the software product into one table for effective sharing of knowledge on the system and its testing requirements.

1. Identify business feature.
2. Identify scenarios under the selected feature.
3. Define steps for each scenario.
4. Run feature and fail.
5. Write code to make steps pass.
6. Refactor code, Create reusable automation library.
7. Run feature and pass.
8. Generate test reports.

In Behavior-Driven Development we user stories to express business value and desired behavior. We see the user of stories in other Agile frameworks as they provide a great way to express what the intended goal is of a requirement, who benefits from it and why, versus expressing it solely in technical terms. This story structure is the basis of discussion between stakeholders in the team or between a stakeholder and a business analyst. 

As you can see on this slide a story would look the way that this diagram shows. So as a role I want a specific feature so that I can enjoy a certain benefit. Depending on the roles you have in your organization, BDD could potentially work as follows. A stakeholder would talk to a business analyst to specify requirements. The business analyst frames that as a user story. The analyst speaks to the tester who creates scope by selecting the most important scenarios. And this implies that the tester works very, very closely with the analyst and with the development team. And then a representative of the technical or development team estimates the development duration.

BDD provides the structure for a story resulting from a discussion between stakeholders and analysts. An example of a user story is displayed. It reads:

• As a <role>
• I want <feature>
• So that <benefit>

There are four steps when discussing Behavior-Driven Development.

1. The stakeholder talks to the analyst to specify requirements.
2. The analyst frames it as a story.
3. The analyst speaks to the tester who creates a scope by selecting the most important scenarios.
4. Finally, a Technical representative estimates the development duration. 

Writing Features

Features, scenarios, and steps together form Behavior tests. These tests are normally written in a business readable, domain specific language (DSL) by Business Analysts (BA) — in most of the cases. Gherkin is a popular language which is used for writing narrative user stories.

In BDD, to start with, the test cases are first defined on the frontend in a human-friendly language, mostly ‘Gherkin’. Once the feature is developed, the test cases are automated in some programming language.

The implementation is kept in the backend, mapping each step to the frontend. The easy-to-understand frontend for a test case in BDD makes an automated test case easy to review for managers and other stakeholders for a project. 

The test cases are defined to replicate the behavior of the system thus the name ‘Behavior Driven Development’.

Thus, whereas TDD begins with a focus on the development of unit tests by developers, BDD starts with a focus on specifying the behavior of the system in a human-friendly format. 

The BDD approach gives clear visibility about the implemented business use cases as the frontend is in plain English. This frontend can be easily reviewed by anyone in the entire team including QA team, Dev team, Business Analyst, sales team and other stakeholders whereas in the TDD approach, automated test cases are tough to review as they are defined by developers in the programming language being used for development.

Below figure shows the process followed by BDD:

In summary, BDD involves in a cycle of above activities and requires the involvement and collaboration of a cross-functional team which consists of customer/client, BAs, QAs, Testers, UI & UX designers, and software developers. 

Behavior-Driven Development specifies that tests of any use of software should be specified in terms of the desired behavior of the unit and should look at the extremely specific business value.

For Review of other Agile Methodologies, follow the links below:

1. Scrum
2. XP - Extreme Programming
3. Lean
4. Kanban
5. Scrumban
6. FDD - Feature Driven Development
7. TDD - Test Driven Development
8. BDD - Behavior Driven Development