Behavior-Driven Development (BDD): A Common Language for Cross-functional Teams

Effective communication is paramount in a cross-functional team delivering a software product to business stakeholders. The development process involves many people, including developers, testers and business analysts, and if they do not use a common communication framework, business requirements and test suites will become unmaintainable over time. A common language framework should be adopted to eliminate the chance of confusion amongst cross-functional team members. The behavior-driven development (BDD) practice can achieve this and much more to accelerate the software development and testing process.

At the core of BDD is a domain-specific language (DSL) which simulates natural language while being unambiguous in its interpretation by the underlying software tool as well as the members of the development team. A common language specification called Gherkin divides business requirements into scenarios which are described as follows:

Scenario: Interest accrued in a savings account

    • Given customer has 500 dollars in account
    • And annual interest is compounded monthly at 10 percent
    • Then customer has 552.36 dollars in account after 1 year

Let us observe some features of this scenario.

Simple and Natural Grammar

The scenario consists of some preconditions and an expected outcome which are indicated by keywords such as “given” and “then.” Note that while each line reads like natural English, it consists of a predefined grammar which is interpreted by the underlying testing framework. Therefore, it is important to strike a balance between the expressiveness of the language and its complexity. The grammar should be rich enough to navigate the problem domain, yet simple enough to implement in software.

Compactness of Presentation

Information is much easier to process and digest when related components are together in one place. However, it is often the case that requirements, test data, and validations reside in different locations. The scenario brings all these elements together and provides the complete context for its evaluation by both technical and business team members. Another benefit is the improvement in requirement traceability. When a different team picks up the development work, it will be much easier to match requirements with test data and assess the quality of test coverage.

Precise Specification

One of the major obstacles hindering the progress of a team arises when there is disagreement on the interpretation of business requirements. The adoption of a domain-specific language, which is agreed upon by all parties, eliminates the problem of ambiguity. After all, the underlying software can interpret the language in only one way.

If you replace the above scenario with a more realistic and complex one, the benefits discussed here become even more evident.
It’s important to emphasize that the grammar of the language is entirely up to the team to decide and should ideally reflect the business domain. If there is already a DSL or declarative language in use at the organization, it would be sensible to adopt that particular language into the BDD framework to achieve even more alignment between development and testing.

The creation of a BDD framework requires significant investment in development, as well as adoption, by both technical and business members for full-scale use, but the potential gains are considerable. The BDD approach will improve communication, increase both test quality and efficiency, and speed up the overall development cycle.