« Table of Contents »
Previous « Background
The Behaviour Specification Handbook
Background
Behaviour-Driven Development (BDD) Overview
The software engineering practices and processes of Behaviour-Driven Development (BDD) that I promote focuses a team on delivering software solutions with high business value, higher quality and less defects. BDD encourages and helps to facilitate close collaboration and clear communication between team members and with business stakeholders.
With BDD, it is possible to deliver solutions that better satisfy actual business requirements and have a lower on-going maintenance and total cost to the business. This can only be achieved however, if the team maintains professional discipline, follows the processes and performs the software development activities, in the recommended order.
One of the key practices in BDD, and the focus of this handbook, is the Behaviour Specification writing sessions. Behaviour Specification writing sessions should be attended by multiple roles in the team, before the coding of a specific piece of functionality is started. This one practice, guided by concrete examples or use cases, has the simple and significant effects of optimising the design, review, and testing feedback cycle by:
- Ensuring what is to be delivered is actually required;
- Ensuring what is to be delivered is valuable to the business;
- Ensuring what is to be delivered is within the agreed scope of functionality;
- Ensuring what is to be delivered is well understood by the team;
- Clearly specifying the required behaviour of each software component in everyday common business language that anyone in the team (including business stakeholders) can understand; and
- Each attendee mentally testing the requirements and software component specifications against the proposed design.
The Behaviour Specification writing sessions encourage and cause important discussions, questions and healthy debates to take place. The result is a common and well-understood, mentally tested and agreed solution — before development has started. There is therefore a significant reduction in the risk of defects and missing or ambiguous functionality early in the software development lifecycle, when it is the cheapest and most appropriate time to have those discussions and identify potential issues.
The clear communication is achieved by everyone in the team discussing required software behaviour or functionality in the business’s everyday common language. If for some reason the common business language unfortunately is ambiguous in some areas, then that is a wonderful opportunity to highlight the risk and show leadership to the business by suggesting and helping to implement some positive, clarifying terminology changes!
As you know, team members will come and go over time. Current and future team members however, may not have the same level of competency, business analysis capability or technical skills. This is why the software specifications are written in the everyday language of the business. Every team member (or interested business stakeholder) who understands the business (the lowest common denominator) — regardless of their technical competency — should be able to understand the functionality that is to be or has been delivered. The total cost over time of software development, maintenance, resourcing and on-boarding is reduced because of this simple concept.
The resulting artefacts typically produced in the process of BDD include living documentation (also known as executable program specifications) and other test assets, such as the test run reports for the executed specifications.
There are many articles available that introduce and discuss the beginnings and benefits of BDD. Instead repeating similar information, below is some recommended reading material:
- Behaviour Driven — Introduction
- Behaviour Driven — Getting the words right
- Dan North — Introducing BDD
- Marko Anastasov — Behavior-driven Development