The goal of a software project is to deliver value to stakeholders and Behaviour-Driven Development, (BDD), is designed for that; keeping focus on value for stakeholders throughout the whole project, Viktor Farcic states when describing his view on BDD.
One principle of BDD is that a requirement has to be written in a way that everyone understands it, Viktor, a software developer working on transitions from waterfall to agile processes, continues. In contrast, in traditional waterfall projects value to stakeholders is in many cases unknown or forgotten. Most people involved in such a project are concerned to “do their part” and throw it “over the wall” to those coming next.
A key to describing requirement in BDD is stories, and Viktor describes the format of such a story as comprising of two elements, a Narrative followed by one or more Scenarios. A narrative is a short, simple description of a feature told from the perspective of a person or role that requires the new functionality, just enough to provide a basis for communication between all involved, (business analysts, developers, testers etc.), and with a focus on dialog instead of a written description. The goal is to answer three questions: What is the value, for whom is it valuable and what is the actual feature. With those questions answered, a team can start defining the best solution in collaboration with stakeholders.
A narrative is further defined through scenarios that provide definition of done and acceptance criteria that confirm that a developed narrative fulfils the expectations.
Although narratives for Viktor have some characteristics of traditional requirements he believes there are important differences. One is the focus on verbal and continuous communication in contrast to using written language which can be very imprecise. Another is the focus on features to describe functionality instead of using numerous statements in the form: “The system shall…” which often prevents the reader from understanding the overall picture and real goal of the project.
Finally, Viktor describes moving BDD towards automation. Execution of BDD scenarios can be accomplished using many different frameworks, e.g. JBehave, Cucumber, SpecFlow and Jasmine. His suggestion is to implement BDD automation in 3 phases:
- Creating a library of normalized steps as a help to separate the scenarios from the actual code, thereby simplifying for non-programmers to write stories.
- Combine steps into composites at a higher business level helping analysts and other alike to a better understanding.
- Use examples tables so that the same scenario may be executed several times with a different set of parameters.
Victor’s recommendation is to start with the first phase, and continue with the following two when enough steps to support the first scenario are created.
BDD was developed around 2006 by Dan North who has written both an introduction and about stories from a BDD perspective.
Specification by Example is a way of defining requirements closely related to BDD.
