Development
BDD Toolbox: Outcome Questioning
Brant DeBow
Written on March 30, 2015
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.
You Might Also Like…
Effective Test Automation in iOS Development
Test automation is probably the single most important factor within an agile software project. Providing a customer with small, working increments of a product, delivered frequently, requires the pipeline from feature design to product delivery to operate very fast. The biggest hurdle in delivering a small change quickly is regression testing. The trouble stems from …