Behaviour Driven Development (BDD) is a business-first approach that puts an agreed definition of ‘success’ at the heart of development and testing.
It’s about proper communication from the outset, getting all stakeholders in the business to set out what ‘done’ really means. This, then becomes the cornerstone of agile development, a vision of ‘success’ that all departments can work towards and test against continuously. When properly implemented, BDD should lead to better productivity, quality, rate of change, and ensure that accurately developed products reach the market fast.
BDD is a powerful technique, popularised by Dan North in the early 2000s, that grew from Test Driven Development (TDD). Developers were realising that TDD wasn’t the right fit for their agile development environment; it didn’t provide proper boundaries or structure for coders, because there was no explicit definition of success built in.
If anything, it asked more questions than it answered: When should we test? What are we testing for? How do we know a test has been successful?
The BDD Difference
BDD is often misinterpreted. It isn’t a testing framework that allows you to automate tests, although such techniques do form part of it. Rather, it’s a way of working that promotes testing for the right reasons, at the right time. It’s about communicating business value within integrated teams, and altering development priority from one that tends to favour implementation to one that also considers proper functionality at every step.
To do this, BDD encourages keeping code repositories and consistent toolsets, as well as making everything accessible and readable to all stakeholders, whatever their technical skills, through the use of natural language.
It’s also about testing more than just code. Before development even begins, BDD leads us to test our assumptions about what the software should do and how it should be constructed. Working through hypothetical situations on use and construction leads to more accurate requirements specifications; these, in turn, create a common understanding and a more efficient and painless development cycle for all involved.
Project owners and BAs working under BDD-enabled Project Managers gain greater flexibility and create better requirements documents. Developers, when all levels are involved in its creation, become less sensitive about criticism and analysis of their code, and improve their focus on the reasons for its creation. Testers find themselves more able to appreciate the user perspective, and their tests become more efficient. At every level, BDD can make a huge difference to the business.
Communication is the key tenet of BDD. There are a number of tools and techniques that can aid the implementation of BDD and the enhancement of agile communication in teams:
Similar to pseudo-code but even more abstract, Gherkin is a writing syntax that puts the ‘what’ in front of the ‘how’. Writing and reading Gherkin’s simple constructed language is an ideal way to structure acceptance criteria and example scenarios, which leads to more accurate software specifications and a much lower defect rate on the tail end.
It’s also inherently testable: Gherkin is an executable specification, created for use with automated testing tools, such as Cucumber and Specflow and others. Check out some examples from the Government Digital Service to see what Gherkin is all about: https://relishapp.com/GDS/whitehall/docs about
The Three Amigos
Unity and communication are, in any agile team, priority number one. The Three Amigos (or Power of Three) concept pushes for pre-development consultation between Dev, QA and business analysts, the latter of which presents the aim of the project and its testing criteria, which is then discussed and developed in combination between the three pillars of its development.
This helps solidify requirements, understanding, and the goal of each part of the development cycle right at its inception, as well as codifying the three elements into a single team. With a combined and co-developed goal, and communication firmly established from the outset, change is easier to handle and can happen much more rapidly.
Strategic planning isn’t easy, but impact mapping, a form of discussion-grown mind map, makes it easier to approach. It breaks down the task into its key goal, the actors who will interact with that goal, the impacts those individual actors will have on the goal, and only then are the deliverables which come from those impacts considered.
This results-first structure aids in doing away with the counterproductive features shopping list, and instills greater understanding of the project up and down the chain.
At every stage of a project, every cog in the machine needs to be aware of which way the others are turning. Living documentation and BDD go hand in hand; as examples are generated for use as acceptance criteria, they’re added to a living document as a matter of course.
This documentation forms the core of the project, and grows and develops alongside it. Written in natural, formulaic language like Gherkin, it is useful for everyone from stakeholders to testers to developers at every stage of the project’s completion, and trickles down to maintenance teams once development is complete.
Test automation frameworks
BDD helps to soften the nervousness around adoption of automated testing; living documentation means the inputs and outputs are available quickly and immediately quantifiable by all involved. Automated frameworks remove human error when properly applied, and drastically reduce workload.
Many companies are employing BDD to great success. The Financial Times uses BDD techniques to structure its projects and ensure that ownership of testing isn’t restricted to developers – it’s a group effort. Says Platform Tech Lead Sarah Wells:
“I knew we were getting somewhere with BDD when our first response to questions about a story we were already working on was to grab the product owner and a tester and add new scenarios into the feature files right there. You can’t easily do that with a unit test.”
There are other major users too – from Paypal to BP to News UK – but the true success of BDD isn’t measured in numbers, it’s measured in less quantifiable metrics: team unity, communication and development efficiency, project success.
Eyes on the prize
It’s important to reiterate that BDD itself isn’t a tool or a testing framework; it’s a ruleset that produces order. It’s a subset of agile development that encourages working from the outside in, putting testing first, and collaborating and communicating efficiently between team members of all levels and roles.
With everyone on the same page, and that page being the correct one, more resources can be spent on progression rather than correction. Knowing what success really means helps to drive teams towards goals in a fast, united fashion. BDD means better products, better communication, and better teams.
If you would like some more information about Behavourial Driven Development, or if you have any questions, please get in touch.