Behaviour Driven Development in a nutshell

Behaviour Driven Development in a nutshell

If you’re new to Behaviour Driven Development (BDD) and don’t understand the jargon surrounding it, this is the article for you. This article will explain the most fundamental concepts as well as the basic implementation of this agile methodology.

Let’s start by clearing up the misconceptions. BDD is not limited to test automation and it is not about tools. Fundamentally, BDD is actually about great communication, where an application is specified and designed by describing in detail how it should behave to an outside observer. In other words, BDD is about working in collaboration to achieve a shared level of understanding where everyone is on the same page. That’s the basic understanding you need to know. Easy enough.

So, what does this ‘great communication’ mean for software development?

Great communication means:

  • A usable product first time round, which allows you to get your product to market faster
  • A lower defect rate and higher overall quality
  • A workflow that allows for rapid change to your software
  • A very efficient and highly productive team

How is it done?

Meet our key stakeholders/teams:

Developers • Testers/QA • Project Manager/Scrum Master • Product Owners/BA

 

To illustrate what happens when you implement BDD, here are the before and after scenarios:

Before implementing BDD

Traditionally, software is designed in a waterfall approach where each stage happens in isolation and is then passed along to the next team. Think conveyor belt factory style:

  1. First the Business Analyst defines requirements
  2. Then the development team work on these requirements and sends for testing
  3. Then testing discovers lots of bugs and sends back to the development team
  4. Things are miscommunicated in transit so repeat steps 2 and 3 back and forth until you run out of time or budget
  5. Release software

The problem here is that everyone is in isolation, interpreting the requirements differently along the way. By the time code is handed in for release, resources are drained, and people are frustrated as there are issues that could have been avoided had everyone just been working together initially.

After implementing BDD

  1. Business and PO/BA have a set of requirements ready to implement
  2. BA, Developers & QA work collaboratively to refine these requirements by defining the behaviour of the software together. Thinking from the point of view of the user, they create detailed user stories. Throughout this process they address the business value of each user story and potential issues relating to QA that may crop up
  3. Each story is given an estimate of how complex it would be to implement
  4. The whole team now has a strong shared understanding of the behaviour of the software and when it will be considered complete
  5. Begin Sprint: Developers & QA then work together or in parallel to produce a product that is ready for release

 

BDD

 

This process saves time and money and is incredibly efficient. The core element of this efficiency is the team’s clear understanding of scope and what the fundamental features and behaviours required are. Because of the collaborative nature of BDD, issues are brought to light that otherwise would be an afterthought. For example, how a feature might behave differently on mobile or how a feature might deal with a large number of users. These are considerations that should be addressed from the outset.

What is the best way to implement BDD?

Just because people are in the same room or present at the same meeting doesn’t mean they will collaborate effectively. Each of the stakeholders play a crucial role and some teams/individuals may need to change their way of doing things to make sure that collaboration actually happens. The image below outlines the key deliverables for everyone involved when adopting BDD:

 

BDD

 

An example of BDD in practice

BDD is a risk-based approach to software development; it mitigates the likelihood of running into issues at crucial times. Teams at ECS Digital have been using the BDD process effectively, including  implementing a website feature for a popular media client. The client wanted to create a swipe feature where more mobile users could swipe to see different articles and move through the sections easily. Everyone was collaborating from the initial stages and the team was able to ensure high quality on the website throughout the process of implementation.

With a clear and shared definition of what the website would be like when completed, they were able to innovate further to mitigate the risk involved. They decided that during times of low traffic they would send users to the new website with the new swipe feature and get feedback. Then during risky times of high traffic users would have the usual website without the new feature. This allowed the team to ensure that when they made the feature a permanent part of the entire website they were taking as little risk as possible.

If this team was not utilising BDD techniques by defining the website’s behaviour in detail and involving each team in the development of requirements, they may have released the feature without such precautionary measures or run into many issues when approaching the release date.

If you’re interested in understanding more about BDD and delving into some of the jargon surrounding it – “gherkin syntax”, “the three amigos”, “impact mapping” & “living documentation” – read our previous article here: Behaviour Driven Development: It’s More Than Just Testing

Kouros AliabadiBehaviour Driven Development in a nutshell
read more
Behaviour Driven Development: It’s More Than Just Testing

Behaviour Driven Development: It’s More Than Just Testing

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.

Recommended tools

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:

Gherkin

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.

Impact Mapping

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.

Living Documentation

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.

BDD success

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.

 

Sarndeep NijjarBehaviour Driven Development: It’s More Than Just Testing
read more