BDD isn’t about the tools. It’s about the conversations you have, exploring examples (or scenarios) of an application’s behaviour, to see if everyone has the right understanding.

Of course, we don’t know what we don’t know, so feedback is still important. We’ve got a good chance of discovering what someone else knows, and has perhaps forgotten to tell us, if we start questioning the ways in which our understanding might be wrong.

These are two patterns which I commonly use. You’ll notice that they follow from the typical BDD scenario template:

Given a context
When an event happens
Then an outcome should occur.

Context Questioning

We can ask, “Is there any other context which, when this event happens, will produce a different outcome?”

It might be an additional context, or a context which occurs instead of the one(s) we’re considering. We can ask this question, or we can think of contexts ourselves and ask about those. For instance:

Given a client manager, Fred, has two clients, George and Henry
When Fred uses the application
Then Fred should only be able to see George and Henry’s accounts.

I ask, “Given I have no client managers, what happens then?” (I’m thinking of handling empty lists, because I’m a developer.)

The head of Client Management says, “What? Who cares? Why are you even using the application? Get on the phone and get some clients already!” (He’s thinking of his failing business.)

You can sometimes learn a lot about a business domain this way, even if the behaviour of the application isn’t going to change immediately!

Outcome Questioning

This is similar to Context Questioning, but instead, we ask,

“Given this context, when this event happens, is there another outcome that’s important? Something we missed, perhaps?”

Another way I like to ask this is, “If pixies were doing this instead of software, would it be enough? Or do they need to do something else, too?”

For instance:

Given the legacy system has a problem
When a trader stores a trade
Then the trader should be told about the problem.

I ask, “Is that all that should happen? I’d be pretty upset if I were a trader and this happened a lot.”

My business analyst (by which I mean, someone who can analyse the business) says, “Well, we’ll still have the details in the system, so you’ll be able to do it again later. Oh, yes! We need to store the trade in our system still, too, but make sure it doesn’t have a legacy system ID so that we can tell it didn’t go through.”

And that’s it.

There are lots of other ways to have conversations around behaviour. They’ll usually be trying to find missing contexts and outcomes – places where a new piece of behaviour happens. These also tend to be the things which business users, familiar with their domains to the point where they don’t think about it, forget to talk about. Developers are pretty good at spotting this, because they’re usually thinking through how they’re going to implement the problem, and wondering what goes on the other side of the “if… else…” statement (even if we’re not meant to be implementing yet, we already are in our heads). Testers are also very good, because they’re used to the kind of things people get wrong when they produce software.

This is why getting all three people – a tester, a developer and a business analyst – is so useful when we’re discussing scenarios. It’s also why it’s so important to have the conversations – because if you’re not having conversations, you’re not doing BDD.