BDD is not about tools

Many teams practicing BDD assume that the tool is the process. A lot of chatter is about: 

• What BDD tool (or framework) should I use?
• How should I use that tool?
• Is tool X better than tool Y?
• Etc., etc, etc. 

So much noise, that I’m afraid the intrinsic value of BDD is lost. Just because you are using a BDD tool, doesn’t mean you are practicing BDD. The tools are important, but not absolutely necessary. You could get a lot out of BDD without a tool. Here’s what I mean.

BDD helps build “Software that matters” 

In order to do that, you should capture requirements as behaviors resulting in a list of “behavior specifications”. In fact, that is what gathering software requirements is all about. You should define what the software should do (i.e. behavior) and frame it in the context of the business value.

But that’s hard.

Waterfall teams tend to write verbose documents, that developers find hard to understand. Agile teams err on the opposite side, writing terse user stories that often do not have enough information. BDD helps bridge the gap with the notion of User Stories that have two components: (a) Narrative and (b) Scenario.  The scenarios are the acceptance criteria and provide examples of how the software should behave. It helps to illustrate the narrative, providing a concise, yet vivid description of the expected business outcome.

You don’t need any new tools to do this.

It provides a language to document the behavior

The narrative is written in the format:

As A [role],

I want a [feature],

so that I [benefit])

The scenario is written in the format:

Given [context]

When [even]

Then [outcome]

This is a very structured way to express behavior.  “Given” describes the context or state of the system, “When” describes the user action or state transition and “Then” describes the outcome or expected behavior.  This expression almost feels like code. Yet it is in a natural language and more importantly, is in the language of the stakeholder. Because of the reduced ambiguity, you are likely to get what you are asking for. Especially, because you are also kind enough to tell the programmer/QA Analyst why a feature is required – a very important aspect of software requirements that is often ignored. Just adopt this format for your software requirements.

You don’t need any new tools to do this.

But it’s more important to discuss the behavior

Don’t just define behaviors, discuss them. Leverage the “Power of Three” i.e. the Business Analyst (a proxy for Customer or Product Owner), the QA Analyst and the Programmer in defining behavior. You can start with having the Business Analyst write the narrative and scenarios for the user story. But be sure to have the QA Analyst and the Programmer review the user story. Good QA people can elaborate the user story. Programmers can keep the specification realistic. Discuss it together, even if only for a brief time. These three stakeholders bring very different perspectives and expertise to the table. You’ll find that the scenarios get fortified with better acceptance-tests, including behaviors that were not originally considered. At the end of the conversation you will also have a definition of “done” for the user story.

You don’t need any new tools to do this.

It’s about baking quality in

Many defects occur because the requirements are ambiguous and subject to the programmer’s interpretation.  BDD fixes this through the scenarios with their rigid grammar. The scenarios provide the cues to the programmer to build the right features.  Defects also occur because the behaviors are not completely defined. This can be fixed by using the “Power of  Three” to inspect the user stories, discuss them and finalize them. This may take some time, but the investment will pay off. As the Toyota Production System says, “Inspection to find defects is waste. Inspection to prevent defects is essential”.

You don’t need any new tools to do this.

Engage the stakeholders

Leverage the “Power of Three” at every opportunity. Include the Business and QA analysts in the design and architecture conversations. Encourage the Programmer and the Business Analyst to review the test cases. When stakeholders, especially those that are more “outside” than “inside”, get involved in design conversations, they are more likely to drive a better understanding of the need and therefore influence the behavior.

You don’t need any new tools to do this.

However, you will need the BDD tools if…

You want to create “Executable Documentation” i.e. you want to record the behavior specifications in the BDD grammar in a BDD tool. Typically, these tools generate skeleton code, against which you write production code following TDD practices. Similar to the XUnit tools, initially tests will fail, and when the behavior is implemented correctly, the tests will pass.  This will provide traceability from the code to the business value.  More importantly, if you are disciplined, you will write just enough code to meet the behavior, thereby reducing waste.

In conclusion

A lot of the intrinsic value of BDD can be realized by:

-  Applying its User Story format

-  Documenting requirements using the recommended grammar

-  Leveraging the “Power of Three” to bake quality in the process

-  Engaging stakeholders to ratify and discover new behavior

And all of this can be done without BDD specific tools.

If you believe you are already following these best practices, then it's time to reach for the BDD tools. But not until then.