BDD Toolbox: Outcome Questioning

BDD Toolbox is an ongoing series of posts in which I’ll give you tools to do Behavior Driven Development well. Today we’ll take a look at Outcome Questioning – a tool to help ensure all relevant details are captured in your scenarios. 

I’ve talked in the past about Behavior Driven Development and how I believe it directly addresses the fundamental problem of software. In fact, Joseph and I gave a talk on that very topic at The App Summit. BDD seeks to increase collaboration and understanding by bringing key resources together for a 3 Amigos meeting. In a 3 Amigos meeting, you work through real world examples of the business rules you’re trying to achieve in your software. One of the key goals is to make sure we’ve captured all of the necessary details that will drive the software we’re building.

Outcome Questioning is a great help to make sure that our scenarios don’t inadvertently miss any key details. I first learned about Outcome Questioning from Liz Keogh in her book on BDD. The basic idea is simply a question we can ask ourselves: Are there any other outcomes that also matter?

Given-When-Then

BDD scenarios are structured in a Given-When-Then syntax:

Given: Sets up a context; puts our system in an initial state
When: Performs an action on our system
Then: Tests the system to ensure the correct outcomes occurred

Most often, the Then clause will be where our tests fail because this is the behavior we’re trying to build into our system. As such, it’s critical that we know our tests represent everything relevant to the business. Remember, BDD scenarios are our acceptance criteria for our application. We must know everything that is needed to make it acceptable, or we will forget to build necessary pieces.

An example

In true BDD fashion, let’s look at an example. Let’s say we have a story about our ATM software: “Withdraw cash”. We take that story into our 3 Amigos meeting and we’ve expanded it into the following BDD scenario:

Given Ralph has an account balance of $250
When he withdraws $20 in cash from the ATM
Then he should receive $20 in cash

This looks like it captures our scenario pretty well. All of us are familiar with withdrawing cash from an ATM and this is spot on. Now, let’s ask Are there any other outcomes that also matter?

If you’re playing along, I hope you spotted the biggest hole in our system: we haven’t debited the money from Ralph’s account. If we had not been careful in our 3 Amigos meeting, we might have missed this detail and run our bank directly out of business. Let’s update our scenario and make sure that doesn’t happen:

Given Ralph has an account balance of $250
When he withdraws $20 in cash from the ATM
Then he should receive $20 in cash
And his account balance should be $230

Now that we’ve captured that key fact, our developers will know we must build it into our system. In addition, we now have a test case that will alert us if it’s not included. We’ve managed to avoid a banking disaster.

Another Tool in the Toolbox

As we’ve seen,Outcome Questioning can be an important tool in your BDD toolbox. It’s a great thing to keep in mind as you write your scenarios with your team; another lens by which to analyze your business and it’s examples.