Skip to content

7. Techniques

7.2 Behaviour Driven Development

Agile Extension to the BABOK® Guide

Behaviour Driven Development (BDD) is used to increase value, decrease waste, and increase communication between stakeholders and delivery teams by focusing on the intended customer behaviour for the solution to satisfy customer needs.

Agile values customer collaboration and working solutions to achieve desired output. Agile business analysis practitioners prioritize identifying solutions which deliver customer value in increments. Behaviour Driven Development (BDD) supports that goal through the use of real examples.

Behaviour Driven Development uses a customer readable, domain specific language to specify the intended customer behaviour which satisfies the customer need. It increases speed of delivery by developing only what is needed and creates opportunity for user acceptance test automation. BDD is a technique used to make needs clear and is designed to improve communication and understanding across all stakeholders. Examples are used to understand what the solution needs to do (development) and how to ensure that it does what is needed (testing). The product owner provides the examples and clarifies his or her thinking by doing so. Agile business analysis practitioners identify scenarios by asking “what if” questions in order to expose additional scenarios and express these as additional examples.

Discussions about solution needs are centered on concrete examples that are easily understandable by stakeholders. This leads to a more stable set of requirements than using abstract models alone. The simple format used in BDD leads to direct collaboration between all stakeholders. Collaborative sessions between the product owner, tester, and developer are frequently used. These sessions are known as “Three Amigos” sessions. Close collaboration encourages the delivery team to think like the customer and deliver only what is necessary to achieve this intended behaviour.

The terms Behaviour Driven Development, Acceptance Test Driven Development, and Specification by Example are commonly used interchangeably.

.1 Examples

Examples are expressions of real life business scenarios provided by stakeholders. Examples may also be known as scenarios and can be expressed in a number of ways including models. Business analysis practitioners facilitate the discovery of the information which is expressed in the examples and ensure that the set of examples is comprehensive.

Examples are used to discover information about the customer, and not all examples identified will necessarily be within the scope of a development effort.

.2 Gherkin Syntax

Behaviour Driven Development uses a simple grammar format, referred to as Gherkin, that allows real scenarios to be filled into the syntax. This takes the form:

GIVEN <a situation>

WHEN <an event>

THEN <expected result>

Both GIVEN statements and multiple THEN outcomes for a single scenario could be compound conditions linked with AND statements. There is only one WHEN event that triggers the scenario.

An example for an ATM:

Scenario 1: Account has sufficient funds.

  • GIVEN: I'm in credit

  • AND: the ATM has sufficient cash available

  • WHEN: I request $20

  • THEN: I receive $20

  • AND: my account balance is reduced by $20

Scenario 2: Account has insufficient funds.

  • GIVEN: I'm in overdraw

  • AND: the ATM has sufficient cash available

  • WHEN: I request $20

  • THEN: I receive no money

Scenarios written in a Behaviour Driven Development format specify events, conditions, and actions are verifiable. They can serve as acceptance criteria for stories and serve as tests in support of Acceptance Test Driven Development that drive a common understanding of requirements and future solution needs.

.3 Testing

There are several software products that will take examples in this format (but may have their own specific syntax and structure) and allow them to be easily converted into automated tests, thus enabling more agile delivery. Automation of examples enhances and speeds up agile analysis verification and validation activities.

.1 Advantages

  • Behaviour Driven Development (BDD) expresses customer needs in natural language, in a format that all team members can easily understand. The language is based on concrete examples rather than abstract concepts.

  • The “Given-When-Then” pattern maps directly onto the “Setup-Execute- Assert" pattern that agile developers use in Test Driven Development. This means the developers can implement the tests directly rather than interpret them.

  • The structure of BDD lends itself towards acceptance test automation and supports the production of effective test cases.

  • Tools exist to support the use of BDD in projects, and these provide additional metrics such as test case coverage or requirements.

  • The automated examples provide the long-term documentation of the system and can be used to demonstrate traceability of requirements for internal stakeholders and external stakeholders such as regulators.

  • Scenarios can be easily prioritized which supports the iterative, incremental nature of agile projects.

  • Allows flexibility of documentation by creating a lightweight, living requirements and testing document.

  • Can be used as acceptance criteria for a user story.

  • The Gherkin Syntax can be used to facilitate and structure design discussions to keep the design team focused on a particular behaviour of the system. This is especially the case when the technique is used backwards on a high level design.

.2 Disadvantages

  • It is possible to miss important scenarios unless there is someone who actively asks the “what if” and “what about” questions.

  • Where business rules are very complex there could be too many scenarios to easily manage and track without tool support.

  • Those maintaining scenarios and test cases must keep them current, relevant, and easy to read to effectively serve their purpose.