What Is Behavior Driven Development in Agile?

Behavior Driven Development

Agile 101

What Is Backlog Refinement?

BDD is a process designed to aid the management and the delivery of software development projects by improving communication between engineers and business professionals. In so doing, BDD ensures all development projects remain focused on delivering what the business actually needs while meeting all requirements of the user.

1 V3Cyc87V 5Oj6Icmweu Fg

Behaviour Driven Development Is Not About Testing

Yes, practicing BDD means you’ll specify and execute tests. But testing is not the purpose.

Because like its TDD (Test Driven Development) companion, BDD is not about testing. It’s about achieving business goals and customer outcomes at the application level. Just like the definition so clearly states.

What’s the Relation Between BDD and Agile?

Well, with BDD you ensure working software over comprehensive documentation at the application level and still get that documentation.

Also, Agile has strong roots in eXtreme Programming. And Dan North—who originated BDD—is a long time eXtreme Programming enthusiast.

Three Amigos as the Core Idea of Behavior Driven Development

The core idea in behaviour driven design is that no one person or field has the full answer to anything.
3 Amigos
You need Three Amigos: business professionals, developers, and testers, for good answers. What’s more, you need them to collaborate. Because it’s the back and forth between people with different cognitive styles and different perspectives and backgrounds, that produces magic. Magic that brings you better, simpler, and more valuable solutions.

What each of the Three Amigos brings to the table:

  • Business professionals bring in the business’ needs and customer requirements. They’re in the best position to decide how desirable a story is compared to others.
  • Developers are the experts on the software and technological opportunities. They’re in the best position to gauge how easy or hard it’ll be to implement a story.
  • Testers are indispensable for their ability to, almost instinctively, spot obstacles and gaps. They’ll identify edge cases before they cause problems further down the line.

What Are the Benefits of BDD?

When you adopt behavior driven development, you can expect these benefits:
  • Putting business goals and customer requirements front and center.
  • Guidelines for structuring the conversation between the Three Amigos. This makes these more effective and productive.
  • Defining acceptance criteria before development begins.
  • Avoiding effort on features that don’t contribute to business goals.
  • Avoiding misinterpretations that lead to redoing work further down the line.
  • Ubiquitous language. A domain specific language that’s used everywhere in the software.
  • Specifications that non-technical people can easily understand.
  • Executable specifications
  1. Automated acceptance tests providing quick feedback to keep implementation on track.
  2. Living specifications that are never out-of-date.
  3. Automatically generated technical and end-user documentation, also never out-of-date.

The Phases of Behavior Driven Development

In BDD you go through three phases for each story you want to implement.
Bdd Practices Flow

These phases are:

  • Discovery. This is where you explore a story in a structured conversation. It has two aims. One is to ensure the story’ll contribute to business outcomes. For example with the Five Whys method. The other aim is to ensure shared understanding of what is required by outlining concrete examples of specific scenarios.
  • Formulation. This is where you rephrase (formulate) the examples in a structured language and turn them into executable specifications. These follow the given-when-then pattern:
  1. the scenario (given)—the initial state, for example ‘the user is logged in’,
  2. The event (when)—what happens, for example ‘the user presses the logout button’,  and
  3. the outcome (then)—the expected response, for example ‘the login page is shown’.
  • Prioritizing items, and re-prioritizing them when you add more details or gain new insights.
  • Identifying risks and obstacles for items close to implementation.

The outcome of these activities should be a Product Backlog that’s DEEP. An acronym coined by Roman Pichler:

  • Automation. This is where you turn the executable specifications into automated acceptance tests. Using tools like Cucumber, this is a matter of connecting the tool to the software.
Working software: The acceptance tests guide your work implementing the software.

A BDD Example

Let’s go through the Discovery and Formulation phases to give you an example. Title: Blocking other users. Narrative: As a member, I want to block users, so that they don’t bother me anymore.

Discovery

The story seems straightforward enough, but questions arise as soon as you start thinking it through:
Bdd Discovery
  • What business outcome is served?
  • What does blocking mean? What does that entail? What do you need to make that happen?
  • What does ‘don’t bother me anymore’ mean? What does that look like? What needs to happen or not happen?

The list goes on and on.

After talking with the customer, it turns out they simply don’t want to see updates from a blocked user in their activity feed. So, you’re left with: as a member, I want to mute users, so that my activity feed does not show their updates. A much simpler issue to tackle and far smaller in scope. Still, even now, it’s not entirely clear what needs to be done and what not. Time to clarify with examples from the user’s perspective.
  • When I mute another user, and that user sends an update, I don’t want to see it in my feed.
  • When I mute another user, and I scroll back in my feed, I don’t want to see any updates from that user.

Formulation

Now you write out each example in the structured notation that can be read and executed by software.
  • Given that I’ve muted |some user|, when I visit my activity feed, then the feed should not contain updates from |some user|.
  • Given that I’ve muted |some user|, when |some user| sends an update, it should not be added to my notifications.

How Not to Get the Most Out of BDD

Common mistakes in behavior driven development are:
  • Leaving out testers in the Discovery and Formulation phases.
  • Assuming that writing down the examples is what counts.
  • Foregoing the Discovery phase because you think you already know what you need to do.

What Is Behavior Driven Testing

Behavior driven testing (BDT) is a lesser known process that leads to automated acceptance testing. Like BDD it promotes collaboration between technical and non-technical people. And it also uses a formalized natural language to write tests that can easily be reviewed and verified by business professionals. But BDT focuses more on what users do with the software. Rather than the acceptance criteria that verify the implementation of business logic.

What Is the Difference Between TDD and BDD?

Behavior driven development and test driven development are similar and different at the same time.
Tdd And Bdd
  • Both employ test-first approaches, but are not about testing.
  1. BDD is about improving collaboration and communication between developers, testers, and business professionals. So that software meets both business objectives and customer requirements.
  2. TDD is about design and specifications at the code level.
  • BDD works at the application and requirements level. TDD focuses on the level of the code that implements those requirements.
  • TDD is, or can be used as the “Make tests pass” phase of BDD.
  • In TDD you can, but don’t need to, use techniques from BDD down to the smallest level of abstraction
  • BDD doesn’t have a refactor phase like TDD.

Start Creating Useful Software Customers Want

The image above illustrates how difficult it is for a customer to describe what they want, and how it gets mangled as it moves down the line. It’s a cliche for a reason, and one with a long history. But using Behavior Driven Development, you can make that a thing of the past. Yes, it can be hard to stop and think, to ‘waste’ time having the conversations that’ll help you do that. But, it’s worth it. You’ll create useful software that customers actually want, and you’ll do it without having to redo, repair, or rework what you’ve done before.

Signup for updates!

Medha Case Study

Check out Nimble Now!

Humanize Work. And be Nimble!

Free Trial