(how) does your system behave

Table of Contents

Key Takeaways

• BDD helps teams define expected behavior in clear, human-readable terms, making it easy for everyone to understand user stories.
• Cross-functional, collaborative teams benefit most from BDD, which fosters alignment and breaks down silos.
• BDD and TDD work best together—BDD ensures you’re building the right things, while TDD ensures you’re building them correctly.
• Behavior mapping and conversation shift understanding left, helping teams identify, discuss, and agree on desired behaviors early.
• Effective BDD depends on teamwork and regular iteration, using real-world scenarios and collaborative exercises to improve practices.

Think of your product or application as a collection of components that provide various features.

Forget for a moment test cases, code coverage, functional specs … if someone asked you to describe the behaviour of your system (or a part of the system), could you describe it in a few minutes?

Enter BDD - or behaviour driven design/development.

GIVEN well-documented, expected behavior
WHEN anyone needs to understand a user story
THEN they can gain alignment from a simple, human-readable pattern

That pattern is all that you need to explain your work in a way that expresses exactly, unambiguously, what your user story is about. It provides an agreed-upon contract between not only developers and testers, but among the whole team.

Everyone, regardless of their technical expertise or deep domain knowledge of a system, can look to and visualize the expected behaviour and understand what must be delivered.

In most cases, teams pass work to each other, which is wasteful. An exception is cases where squads are small, cross-functional teams that own end-to-end responsibility for their work. On most teams, some people code and others test. Some teams also include extended members who split focus between efforts. Many teams can’t complete a user story without depending on another team. This is where shift-left and the Garage Method can help to break down walls and silos within your delivery and enable agile teams to deliver faster, better and more consistently.

The fact that stories must move across teams works against those in the example above. Many software development methodologies, such as agile, design thinking, and DevOps show that cross-functional teams are the ideal: not teams of only UI developers, or back-end developers, or content developers, but teams that can craft a story from start to finish within the team. With a cross-functional, multi-disciplined team - you can truly embrace the Garage methods and reap the benefits of DevOps and shift-left at a massive scale.

Traditionally, test-driven development (TDD) focuses on only the components, not on larger features or how the components work together. There are challenges in demonstrating whether two components can interact successfully to deliver the intended functional behaviour (usually, you can’t with any degree of confidence). While the component itself might behave perfectly, the overall behaviour of the system may not match your expectations.

When you write tests that are driven by components, not features or overall expected behaviour, the test can express only the expected behaviour of the components. These types of tests make sense only to the engineers; product owners and other stakeholders rarely participate. This style of testing can also lead to situations where all the unit tests pass, but the product is still broken.

Alternatively, BDD focuses on the features as they are developed, ensuring that the feature works as intended, going across components.

Some people refer to BDD as “TDD done right”. I prefer to think rather than a one or the other scenario, you should be able to have the best of both worlds. The benefits of BDD and TDD, demonstrated hand-in-hand. You should think of BDD as “how we build the right thing” and TDD as “how we build the thing right”. Then you can understand, they can and should co-exist.

So, how does this translate into agile delivery? What do you do differently to enable these benefits for your team?

A behaviour mapping exercise can unlock the understanding of your intended behaviour, across your squad/team. A simple mural board with the context of your system in the centre, and start to think about the paths (stories) of your system and the results of different paths from a behavioural point of view.

This sort of common understanding and thought-provoking process puts a team in an excellent position to start to think about the scenarios involving these behaviours and the system’s expected behaviour during conversations around user stories.

This encompasses the shift-left methodology - pushing the conversations and understanding about the expected and accepted behaviours of a system as far left as possible - enabling common understanding of that expected behaviour from the beginning.

While you organize around squads and “whole teams,” you must communicate the needs of one team to another. You also must communicate to all of your stakeholders what behaviours are completed. BDD can help you do that.

Ideally, you should then define and test your user stories in two ways:

1. With BDD tests that prove that the stories do what they were meant to
2. With TDD tests that confirm that the components work correctly

When you use BDD with Enterprise Design Thinking, you can create concrete acceptance criteria for your user stories that you can turn into executable tests.

Some tips from me for enabling and executing effective conversations around BDD:

Think about the behaviour of the system and scenarios, not the test cases

e.g. instead of “perform multiple simultaneous updates on the database to ensure there are no conflicts” the desired behaviour should be described by something like “updates to data model should be concurrency safe and idempotent”

Non-functional behaviours should be described only if known against the parts of the system

e.g. API should support X requests/day, DB load should allow X simultaneous connections

You should use the Three Amigos model

There should not be contributions from within a silo, it’s best driven as a collaborative effort across a squad and including non-technical stakeholders (Product owner/dev/QA collaborate so effectively at this level!)

Try not to think about the test implementation too much at this point

Try to shift your perspective, think about the specifications of the behaviour of the model instead of the unit tests of a model, and specifications of the product’s behaviour instead of functional tests

So what’s next?

Start with your user stories. As a team, examine your user stories and write BDD scenarios by using the keywords GIVEN, WHEN, and THEN. You can also use AND for more complex scenarios.

As a team, pick a framework so that you can practice BDD in every language, write only the code that you need to make the BDD scenarios pass or “go green”.

Build your BDD test suites into your pipelines and ensure maximum coverage of the expected behaviours of your system and the scenarios identified by your workshops.

Make sure that your BDD is an iterative effort. Work within your teams, identify what works and what doesn’t. Repeat.