Behaviour Driven Development, not just for Developers

Behaviour Driven Development (BDD), that’s just a technique for programmers, right? Well no actually it isn’t. In fact if it’s only being done by the Development team then you’re missing a key part of it – Conversation. This is where the power of BDD truly lies. Conversations between the Development Team, Customer and Tester.

Rather than passing requirements and conversations down the line, where they can get lost in translation or misunderstood, BDD encourages collaboration to create shared understanding and most importantly allow thought-provoking or clarification questions that can improve an overall design or solution for everyones benefit, especially the Customers.

Agile and BDD are all about collaboration.

BDD is all about collaboration and conversation.

The key concepts of BDD;

• Early conversations with the team, including BA, PO, QA & UI/UX
• Ubiquitous language
• Concrete examples to focus on behaviour of a system
• Examples translated to automated tests

Early conversations with the team, including BA, PO, QA & UI/UX

These are crucial to ensure everyone is up to speed and has the opportunity to contribute to the process. There is no point in having a capable, diverse team if you don’t engage them in the process. People in different roles will have different experiences that will enrich the conversation. Asking questions reveal more of the hidden details, providing clarity and helping to shape and add depth to a design or solution.

Having QA involved ensures this is not just an afterthought and that testing is baked in from the start. BDD in conjunction with Test Driven Development (TDD) promotes a test first methodology, creating well tested software and if done right with good Software Engineering techniques (such as SOLID), cleaner codebase, which in turn can help ensure features don’t take longer to deliver as the codebase size increased (which is all too often the case in many projects).

One problem with a linear approach to requirements is the Chinese whispers effect, where the meaning or intent can get lost the further it is passed down the line. If UI or UX are at the end of the chain, do they have a clear enough understanding of the software being delivered? Another problem – what do you lose by missing these conversations? No one person has all the answers, not even the Customer can know everything, its only by having conversations and questions, can you really add depth to the requirements capture and ensure that depth is retained throughout the process.

It’s not always possible or practical to have the Customer present, but what is key is that the customer is represented.

Ubiquitous language

Use the same language throughout. Problems can arise when Stakeholders are using business language, but the development team use their own vocabulary. This adds overhead to translate, it’s also a prime location for bugs. Agree a clear and consistent terminology and use it throughout the software. In the worst cases, the same work can mean very different things for the Stakeholders and the Development team, ultimately leading to confusion, and lost time or bugs.

Concrete examples to focus on behaviour of a system

It’s all about behaviour. Focus on what the Software should do to ensure everything is adding value. This can help over over-engineering, just deliver the features that matter. Of course best practice Software Engineering should always be enforced by the Development to ensure that software is well written, and easy to change as requirements evolve over time.

The concrete examples are the requirements, written in a language everyone can understand. These can then easily become the User Stories with acceptance criteria.

Examples translated to automated tests

To get the most from BDD, use frameworks such as Cucumber, so the concrete examples become part of a fully automated test suite. Cucumber uses Gherkin Syntax (Given, When Then), to define the test steps and read like plain English. These can be written (and should be) before coding begins and they can be written by anyone, Developer, QA, Product Owner. For the best results, conversation and collaboration between all interest parties with diverse views and thinking will give the best concrete examples and therefore the best automated tests.

The steps are then mapped to executable code using regular expressions allow them to be run in an automated test suite, such as JUnit.

Using a Concrete Example with Cumber might produce something like this….

Benefits include;

• It’s clear and can be understood by anyone
• The scenario focuses on Behaviour of the system 
• It can be an automated test
• It now acts as living documentation of what the system does (that’s never out of date)