Behavior Driven Development (BDD): Value Through Collaboration (Part 1: Introduction)

This post is part of the “Behavior Driven Development (BDD): Value Through Collaboration” series.

• Part 1: Introduction
• Part 2: Narrative
• Part 3: Scenarios
• Part 4: Automation

Introduction

The goal of software projects is to deliver value to stakeholders. Even though that might sound an obvious statement, it can be easily forgotten in traditional Waterfall projects. The very nature of the Waterfall process fosters the creation of different departments whose job is to receive work from the previous stage, produce something, and pass it on.

A simplified Waterfall model would be:

1. Requirements specification resulting in requirements document
2. Design resulting in software architecture document
3. Development resulting in actual software
4. Integration
5. Testing
6. Installation
7. Maintenance

Each of these phases tends to have separate teams and departments. BAs work with requirements, architects write design documents, developers code, integration engineers integrate, testers test, and someone installs the software. Each of these departments is waiting for others to produce something, to start working on their artifacts and, once finished, to pass it on to someone else. The value for the stakeholders is, in many cases, unknown or forgotten. Most people involved in such projects are concerned about “doing their part” and throw it “over the wall” to those coming next. Moreover, artifacts produced by one team are often not used or understood by another.

Testing and deployment tends to occur towards the end of the project. As a result, Waterfall tends to identify problems late in the development cycle. Lessons are learned after the project is finished and can be applied only in the next project.

Behavior-Driven Development (BDD) is an agile process designed to keep the focus on stakeholder value throughout the whole project. The premise of BDD is that the requirement has to be written in a way that everyone understands it – business representative, analyst, developer, tester, manager, etc. The key is to have a unique set of artifacts that are understood and used by everyone. A BDD story is written by the whole team and used as both requirements and executable test cases. It is a way to perform test-driven development (TDD) with a clarity that can not be accomplished with unit testing. It is a way to describe and test functionality in (almost) natural language.

BDD Story Format

Even though there are different variations of the BDD story template, they all have two common elements: narrative and scenario. Each narrative is followed by one or more scenarios.

The BDD story format looks like this:

Narrative:
In order to [benefit]
As a [role]
I want to [feature]

Scenario: [description]
Given [context or precondition]
When [event or action]
Then [outcome validation]

Next post Behavior Driven Development (BDD): Value Through Collaboration (Part 2: Narrative) explains Narrative in more depth.