Behavior Driven Development (BDD)

Overview

Behavior-Driven Development (BDD) is a set of software engineering practices designed to improve collaboration between technical and non-technical stakeholders of a project in order to deliver quality software faster.

BDD practitioners start by identifying business goals and looking for features that will help deliver these goals. Collaborating with the user, they use concrete examples to illustrate these features. Wherever possible, these examples are automated in the form of executable specifications, which both validate the software and provide automatically updated technical and functional documentation.

Speed up your development using BDD principles

• Identify business goals: It is necessary to understand and identify your business goals in order to have a successful project.
• Focus on features that deliver business value: Build features that contribute to your business goals. Features represent the high-level functionalities that the software should have

• Work together to specify features:  Business analysts, software developers, and quality assurance (QA) testers work together with the end users to define and specify features, drawing ideas from their individual experience and professional capabilities.

• Illustrate features with concrete examples:  The team works together with users and other stakeholders to define stories and scenarios of what users expect this feature to deliver. In particular, the users help define a set of concrete examples that illustrate key outcomes of the feature. These examples use a common vocabulary and can be readily understood by both end users and members of the development team.

• Don’t write automated tests, write executable specifications: These concrete examples are translated into executable specifications, which involves writing automated tests or scenarios that illustrate and verify how the application delivers a specific business requirement. These automated tests run as part of the build process and run whenever a change is made to the application. In this way, they serve both as acceptance tests, determining which new features are complete, and as regression tests, ensuring that new changes haven’t broken any existing features

• Deliver living documentation: The reports produced by executable specifications aren’t simply technical reports for developers but effectively become a form of product documentation for the whole team, expressed in a vocabulary familiar to users. This documentation is always up to date and requires little or no manual maintenance. It’s automatically produced from the latest version of the application. Each application feature is described in readable terms and is illustrated by a few key examples. For web applications, this sort of living documentation often also includes screenshots of the application for each feature.

Benefits of BDD usage

• Reduced waste: BDD is all about focusing the development effort on discovering and delivering the features that will provide business value, and avoiding those that don’t. When a team builds a feature that’s not aligned with the business goals underlying the project, the effort is wasted for the business. Similarly, when a team writes a feature that the business needs, but in a way that’s not useful to the business, the team will need to rework the feature to fit the bill, resulting in yet more waste. BDD helps avoid this sort of wasted effort by helping teams focus on features that are aligned with business goals. BDD also reduces wasted effort by enabling faster, more useful feedback to users. This helps teams make changes sooner rather than later.
• Reduced costs: The direct consequence of this reduced waste is to reduce costs. By focusing on building features with demonstrable business value (building the right software), and not wasting effort on features of little value, you can reduce the cost of delivering a viable product to your users. And by improving the quality of the application code (building the software right), you reduce the number of bugs, and therefore the cost of fixing these bugs, as well as the cost associated with the delays these bugs would cause.
• Easier & safer changes: BDD makes it considerably easier to change and extend your applications. Living documentation is generated from the executable specifications using terms that stakeholders are familiar with. This makes it much easier for stakeholders to understand what the application actually does. The low-level executable specifications also act as technical documentation for developers, making it easier for them to understand the existing code base and to make their own changes. BDD practices produce a comprehensive set of automated acceptance and unit tests, which reduces the risk of regressions caused by any new changes to the application.
• Faster releases: These comprehensive automated tests also speed up the release cycle considerably. Testers are no longer required to carry out long manual testing sessions before each new release. Instead, they can use the automated acceptance tests as a starting point, and spend their time more productively and efficiently on exploratory tests and other nontrivial manual tests.