Behavioural Driven Development - A Story About Change

A Story About Change

Discoveries are a natural part of the software project lifecycle. Every project starts with a vision and set of goals from the project owner and stakeholders.

The project goals are then handed to UX, Design, and Engineering who turn them into features and code. Then in an ideal project the features all help fulfill a single goal and the codebase has a clear separation of concerns. This ideal project does not exist.

Real projects have features which depend on one another, conflict with each other, or were never actually necessary. These are the real project stories that any experienced engineer can tell you.

Behavioural Driven Development

Behavioural Driven Development (BDD) is a framework that uses examples to create a shared understanding and surface uncertainty to deliver software that matters. Together the team writes examples creating a conversation around why a feature exists and how it should work. The examples can also used by engineers to write tests as part of Test Driven Development (TDD).

The BDD document is a feature list with user stories, acceptance criteria, and written examples using the Gherkin syntax. The Gherkin syntax is regular english which breaks down a feature using a Given, When, and Then format. Given is the background, When is the action, and Then is the outcome that should occur. The gherkin syntax is testable by engineers and QA testers.

One of the keys to writing Gherkin is using the word “should”. Should invites conversation and allows you to think about all the outcomes that could or could not occur. Should invites others to question the outcome of an example. Another key to Gherkin is writing your features and user stories in a declarative style. Declarative user stories say what the feature is without saying how it will be implemented.

Documentation Driven Development

Often the project stakeholders initial feature list is incomplete or the project goals even conflict with one another. Then engineers are tasked to build a complete solution. Finally when the project is handed off for QA it needs significant rework or additional features added at the very end of a project which leads to bugs and developer burnout.

By having the entire team including the key stakeholder, UX/strategy, and engineers write the BDD document together at the beginning of a project, they get to ask each other how a complex feature should work and why it even exists in the first place.

The BDD documentation drives the features priority and what features are in scope. The team can present examples to the client and together they decide what features are a must have, a should have, or a nice to have. Together TDD and BDD decrease the amount of rework and bugs in the final project while increasing the testability of the codebase.

Creating a Culture of Documentation and Testing

Team leaders can start by setting up a BDD document and outlining the process. Then helping the team adopt TDD, setup peer-to-peer mentors, and share stories of when it helped you.

By sharing the teams wins, and celebrating people’s success, you help the team level up and improve from within.

Written by Ehren Graber who lives and works in Vancouver, Canada building useful things.