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.
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.