BDD & the Holy Grail of User Story Testability & Traceability

The Holy Grail of Requirements has always been traceability, measurability and perhaps most importantly testability. The evolution of requirements has gone through various iterations: Use Cases, MosCow analysis and perhaps most usefully, Agile User Stories.

The User Story template format of “As a [User] I want to [do something] to [achieve business goal]” is a great step forward in requirements definition, as it clearly frames a desired outcome and cuts through the old school clutter that invited people to mix features, outcomes, data, data validation and behavior into an amorphous blob of unreadability.

Anatomy of testable & traceable requirements

Conditions of Satisfaction - where User Stories usually break down
The acceptance criteria and detailed requirements of User Stories are normally written down as Conditions of Satisfaction on a story. This is usually where User Stories break down and fall into all the same traps as other methods: vagueness, mixture of intent and data, internally inconsistent and contradictory conditions etc.

Behavior Driven Development to the rescue!

Consider the box “Scenario 2” in the first diagram of this post, then consider the code above (swiped from the Java BDD framework JBehave’s website).

Notice anything? If you take a similar “template” oriented approach to writing Conditions of Satisfaction as you do to writing User Stories, you can effectively write Conditions of Satisfaction that are easily translated into assertable test code:

Scenario 1: Title
Given [context]
When [event]
Then [assertable outcome]

For instance, a full User Story, from story to conditions of satisfaction could read as follows (taken from Dan North’s excellent post “What’s in a User Story?”):

Story: Account Holder withdraws cash
As an Account Holder
I want to withdraw cash from an ATM
So that I can get money when the bank is closed

Conditions of Satisfaction
Scenario 1: Account has sufficient funds
Given the account balance is \$100
And the card is valid
And the machine contains enough money
When the Account Holder requests \$20
Then the ATM should dispense \$20
And the account balance should be \$80
And the card should be returned

Scenario 2: Account has insufficient funds
Given the account balance is \$10
And the card is valid
And the machine contains enough money
When the Account Holder requests \$20
Then the ATM should not dispense any money
And the ATM should say there are insufficient funds
And the account balance should be \$20
And the card should be returned
…

Achieving the Holy Grail of Requirements
In summary, we can achieve the holy grail of requirements in terms of readability, traceability, measurability and testability by doing a few simple things consistently:

• Write User Stories in a template style as Scrum prescribes.
• Write Conditions of Satisfaction in a Scenario template style as mentioned in this post.
• Write Behavior Driven Test Cases closely matching the wording of Scenarios.

The close match between actual Test Cases and the Scenarios themselves will cut down on communication overhead, not to mention enforce a level of discipline from fuzziness for both the business and developers, as Scenarios must be testable/assertable and internally consistent.

“Behavior Driven Development”, what about Test Driven Development?
To me, BDD is TDD “done right”: it is effectively an evolutionary step forward from TDD that puts tests closer to the actual business requirements. It is true that down at the granular “unit”-level, tests simply won’t match directly to a business requirement scenario, but if you think about API’s in the same way as you do about User Stories, you’ll soon realise that a similar Scenario-driven approach to testing your API’s is very easy to apply at the class level of your code.

“Where do I start?” and final words
The thing that held me back from BDD for a long time was not quite getting the link between requirement, test and consistency of expressing requirements in a testable manner. I was writing Unit-tests in a “BDD” manner, but without expressing them in a close to natural language way. Eventually the penny dropped in seeing BDD as the missing link between TDD, Automated Acceptance Tests and Conditions of Satisfaction.

For those interested in BDD, there are a multitude of frameworks out there that should slot nicely into any development environment you have. I have already mentioned JBehave, but there is als JDave for Java, RSpec for Ruby and Specs for Scala.