Behaviour Driven Development. A better Agile?
Or just a natural next step in the right direction?
[NB: this article by our Technical Director Kevin Smith, assumes that you are familiar with Agile software development methodologies]
Over the last few months, we’ve been dipping our toes into the largely uncharted waters of Behaviour Driven Development, or BDD for short. This post explores some of the things we have learnt along the way; What is it? Why bother? What problems does it solve? What problems doesn’t it solve? Should you care?
We are Agile up to the hilt, so why bother with BDD?
Firstly BDD does not replace Agile it merely improves upon it, introducing a few more tools into your Agile toolbox. What needs improving you may ask? Well, after many years of running Agile projects we started to notice a few things:
1. User stories are focused very much around the persona of the user and what they are trying to achieve. A user story does not necessarily focus on why the business is in need of this new feature. This can get overlooked at sprint planning meetings and the developers end up sympathising with the users and not necessarily the needs of the business.
2. User stories are fleeting. In long running projects work done in one user story can be easily superseded by a later one. That’s fine, but what about the overall specification of the product? The tools in the Agile toolbox have typically had very little to do with owning this specification and keeping it up to date.
3. Acceptance criteria, the stuff that lets you know when a user story is functionally complete, can be ad-hoc and prone to vary in quality. The acceptance criteria often does not say enough to enable the creation of robust tests. It’s also a problem if the user story is driving the tests, because as we have already said, a user story is transient in nature and may be superseded later on. This creates a traceability issue and a lot of grunt work to keep everything up to date.
4. There are very few tools in the Agile toolbox that help you at the discovery stage. Your technical pre-sales team will not be speaking the same language as your development team. At the business opportunity stage, how do you decide what problems you should be trying to solve first or even work out what those problems are?
5. In many cases Agile teams adopt test driven development (TDD) by default. The problem with TDD is it is a costly bottom up approach; You can end up with hundreds of tests at the nuts and bolts level without ever having a test that proves you have created a feature that actually delivers the promised value.
We have found that BDD attempts to address all of these issues and more. While it remains the case that ‘there is no silver bullet’, BDD goes a step further in tackling some of the gaps and re-orienting the Agile process.
For us, it has bought immediate new value by introducing us to the following concepts:
- Specification by Example
- Formalised Acceptance Criteria
- Living Documentation
- Impact Mapping and Deliberate Discovery
Business Benefit
Perhaps the simplest change we made as a result of our move into BDD is that of re-framing our user stories. There are a few user story templates around, but the one that we had used up until recently was “As a <role> I want <feature> so that I can <benefit>”. While BDD is fine with this, it does propose an alternative: “In order to <realise benefit> as a <role> I want <feature>.
We found that with BDD’s increased focus on business goals and business value it made sense to shift the emphasis of our stories away from the user and in favour of the value proposition.
While this change is subtle it does make a lot of sense; it may make little difference to a developer but it’s useful for a business stakeholder to discuss stories in this way. It ensures the business value is always discussed and understood up front in planning meetings. It also overcomes the temptation to ditch the value entirely and end up with stories that are simply of the form “As <user> I want <feature>”, as can often become the case.
Examples, Examples, Examples
BDD places a heavy emphasis on the use of concrete examples to try and squash ambiguity. These are used both during discovery and when writing the acceptance criteria.
How many times have you read a line item in a specification and not been able to make head nor tail of it? How many times have you had a conversation with a client or a supplier and only found out later that you both had different versions of what you thought you had agreed?
Examples are the magic mojo in BDD teams that make sure everyone is singing from the same song sheet. Not only do they spell out clearly to all parties what the current understanding is, they also uncover the gaps. An example can facilitate a conversation that can uncover missing or assumed functionality. The conversation may beg the question as to why a particular feature is there in the first place. Perhaps there is a better way?
To help ensure these examples are communicated as clearly as possible, a formal syntax is introduced with which they are written. This is called Gherkin (because all good things deserve an obscure vegetable based name?) and using it to formally communicate scenarios and acceptance criteria has two advantages:
1. Distinct features of an application can be communicated effectively between all members of the project team, from product owner through to business analysts through to software developers through to test engineers.
2. A formal syntax allows for automated tooling. If a computer can easily process and understand the syntax, then tools can be developed to write tests based on these examples or produce documentation about them.
An Example of a BDD Scenario written in Gherkin, using the ‘Given, When, Then’ syntax
Scenario: Find the optimal itinerary between stations on the same line
Given South West Trains leave Portsmouth Harbour for London Waterloo at 07:13, 07:24, 07:29, 07:45, 07:55
When I want to travel from Portsmouth Harbour to London Waterloo at 07:15
Then I should be told about the trains at 07:24, 07:29, 07:45
Features, Scenarios and Living Documentation
Since starting with Agile development several years ago, we have watched and helped others to do the same. On more than one occasion the same false idea surfaced: “What if you could generate the specification from the user stories”? It is a tempting solution to the evolving documentation problem. Ideally, you need to document the feature set of the software but this cannot be done upfront and it requires continual manual attention. It is an evolving document that no one wants to write. The problem with looking to user stories for the answer is that user stories are typically:
1.Not complete, often with poor acceptance criteria.
2.A temporary work item or artefact that is quickly superseded or augmented by other stories.
BDD, on the other hand, is all about the features. You will find yourself writing lots of feature files, both before, during and after you write the user stories. Features define what the software does. Example scenarios explain how a feature behaves. And user stories are created as ‘developer tasks’ to ensure part of a feature is implemented.
The user story should reference the scenario it is trying to cover off and, in-fact, scenarios are often uncovered when discussing the particulars of a user story at a sprint planning meeting. In this case, the scenario is added into the feature and the feature becomes more complete and better understood by all. It’s this iterative understanding and development of the products feature set which BDD does so well.
A natural output of the process is a set of features, complete with examples that can be turned into a specification. Even better, the creation of this document can be automated. This is called Living Documentation. And we think it’s great.
Automated Testing
Automation is a bit like…well, let’s just say lots of people talk about it, but they don’t always do a lot of it. There are good reasons for this, especially for short lived projects where the cost often outweighs the benefits. However, there is no doubt that to get the maximum benefit from BDD, test automation is something that needs to be taken seriously.
There are numerous BDD tools that promote and facilitate automated testing allowing you to generate test stubs straight from BDD style scenarios written using Gherkin. This is great for two main reasons:
1. Your tests are based on the same examples the entire team are already familiar with.
2. Your tests are written from the top, down rather than from the bottom up. NB: This does not prevent finer grained testing by any means, but your testing can be more pragmatic at the nuts and bolts level if need be.
Full disclosure: We have run some BDD style projects without using test automation (gasp!) and we have found that it did leave us wanting . The concrete examples and scenarios that you write for each feature can be quite high level. They are a great starting point for testing but more detailed and prescribed tests will have to be written and maintained. This leaves you with two choices: 1) write and maintain more detailed manual test scripts 2) write a suite of automated tests fanning out from a particular scenario.
Either way, the end result needs to form part of your product documentation and regression testing suite. Automation is clearly a nicer approach and lends itself well to BDD style iterative development.
Mind the Gap
So this is all good right? We have gone from a bunch of transient user stories that could be vague and mis-communicated, to a formalised set of features and examples that can be used to generate documentation, tests and ultimately a living specification. Well yes, we think BDD does have a lot to offer but you still need to be aware of some of the potential gaps.
1. BDD has nothing to say about the visuals. In fact, it tries to avoid them. As such your feature based specification should not live alone. It may detail what the system is expected to do, but not necessarily how it is expected to do it. To deal with this, we create both wireframes and interactive visual prototypes for all the products we work on. This ensures that the UX is properly explored and designed and goes on to form the visual specification of the product.
2. There are quite a lot of tools that let you create tests from the written examples and report on the resulting test coverage. However, often you still need to record what tests were done, by whom, on what date. Typically you would use a dedicated test management tool for this but many of them are still not speaking the same language as BDD, so if that matters to you, you will have to chose carefully.
3. While there are obvious benefits in automated testing, it can be hard to achieve in practice. You need testers who can code and who need to be part of your scrum team (or similar). This is particularly problematic for companies who outsource their QA. There are no two ways about it, automated testing is more expensive in the short term.
4. It’s still relatively early days for BDD. Agile has been around for more than 20 years and yet we still find ourselves helping companies to embrace it today. With BDD, the books, tooling and software ecosystems are nowhere near as strong as they have now become around traditional Agile development.
Summary
We started our Agile journey just five years ago. In the time since then we have managed to create highly proficient and highly performing Agile teams. Believe it or not, we were still considered as early adopters despite the fact we were embracing an idea that was already 15 years old.
BDD seems to be in the same place Agile was five years ago. Maybe we are even a little earlier to the game this time round. It is not a replacement for Agile. It is not as disruptive as the move to Agile was, and can be. It is not a fundamentally new idea for anyone who has already had to transition away from waterfall style development.
What BDD is, we think, is a natural next step in the right direction. It addresses some of the gaps and recognises that software development is so fundamental to business today that software developers need better ways to communicate with business stakeholders and business stakeholders need better ways to communicate with software developers.
To echo the wise words of Dan North, an authoritative voice and the founding father of BDD. “Above all BDD is a mechanism for fostering collaboration and discovery through examples.” It is important to remember that when you strip it all right back, Agile development, and now BDD, are really all about better ways of communicating.
We’re always looking to improve what we do and to learn from anyone and everyone so would appreciate any and all feedback, advice or opinions on BDD and Agile. Either comment or respond below, or get in touch directly.
Kevin Smith is Technical Director and Co-founder of Dootrix . Beautiful design. Rock solid engineering. Software built with both sides of the brain.
