Behavior Driven Development (BDD) distills earlier established DevOps practices like Test Driven Development (TDD) with additional disciplines and practices that are designed for their enhancement. Central to BDD are the Five Why’s (a technique originally used by Toyota), which are applied to each user story.
The objective of BDD is to minimize waste by focusing specifically on those aspects of the organization’s behavior in which the development project will ensure a positive impact on business outcomes.
A DevOps team can easily waste time and money on elements of an organization’s technical requirements that are either not of immediate importance or irrelevant to a project. BDD helps the team to get a clear picture of behaviors in a single notation format that easily can be accessed by experts, testers and developers. It serves as a map and a key, supporting communications within the team.
A good BDD team will apply these techniques down to the lowest level of abstraction of the software involved.
BDD first originated in 2003 with agiledox, a tool for generating technical documentation automatically from Junit tests. JBehave was released by Dan North in 2004 in order to test his hypothesis about de-emphasizing the use of terminology around testing to focus on the more behavioral aspects of DevOps.
Collaborating with Chris Martin, in 2006, North proposed a “given-when- then†canvas which expanded the scope of BDD to cover business analysis. Since then, several other tools have been released that have confirmed the DevOps community’s investment in BDD. These have included RSpec and Cucumber.
DevOps teams using BDD should be able to generate user stories that are fully supported with realistic scenarios and examples. It extends the thinking of programmers beyond the technical issues of simply testing to actually focusing on the user scenarios involved. They should be asking questions such as: Will this work in practice? Will this make things better?