Financial ServicesProviders Company Schemes Public Sector Third Party Administrators

Behaviour-Driven Development

Shahid Jamil

Business Systems Analyst

discusses Behaviour-Driven Development in Agile environments

2 February 2018

In the past, at Aquila Heywood, we followed a very traditional approach to software development. The requirements were primarily gathered from the users by consultants and refined by business analysts, then converted into a 'cast-in-stone' specification and handed over to the development teams. The benefit presumably was that everything was written down and a two-level approach of verification could be applied. This meant that developers and testers followed a single specification and reached the same desired conclusion: the product deliverable.

Traditional approach

It works in theory, but the problem in practice is that things get lost in translation. Ask two people to describe the same problem and they will explain it in completely different ways. When it comes to complex solutions, a lot more needs to be communicated than just a specification. Additionally, when using a traditional approach, the feedback loop is too long. By the time the user receives the final product, it is often too late and costly to change things.

I'm sure you have all come across the below image on the Internet. The creator probably intended it as joke but, if you think about it seriously for a second, you will realise that it depicts the reality of traditional software development very closely. All six pictures show the same product from a slightly different perspective. Each perspective is based on the same basic components and features (swing mechanism, a rope, support from the tree) and yet the final product is entirely different and - dare I say? - not suitable for purpose.

Why projects fail

As Aquila Heywood shifted towards Agile, we introduced and adopted a Behaviour-Driven Development (or BDD) approach. This is a software development process that promotes communication - lots and lots of it. Unlike a traditional approach, there are no strict roles for developers or testers and no designated business person who is the only communication channel between the developers and the user. BDD blurs all the lines that were traditionally considered good practice. And yet it somehow works!

So how does it work? The BDD approach uses a series of examples or 'behaviours' (also called 'features') to explain what the final product should do. It all starts with a simple description of the behaviour. This is refined – a process where all the stakeholders are involved. The value in this is that communication with the end user happens at all stages of the process. The feedback loop is, therefore, very short and ensures that the user gets the product they want, rather than a distorted interpretation. The product is potentially shippable at the end of each sprint. The user is able to see the product quickly, so any changes or enhancements can be incorporated through a system of 'inspect and adapt': a big improvement over our earlier practices.

Behaviour Driven Development - BDD

Here are a few BDD highlights that we at Aquila Heywood have come to admire particularly:

  • User involved at all stages
  • No distinction between developer and tester
  • Bridging communication gap between 'techies' and business users
  • Features as a contract
  • 'Living' documentation
  • Short feedback loop
  • Functional assumptions verified by the customer
  • Business-readable Domain-Specific Language (DSL) such as Gherkin
  • Reusable steps
  • Clear business objectives
  • Supports industry-standard testing concepts
Shahid Jamil is a Business Systems Analyst at Aquila Heywood, the largest supplier of life and pensions administration software solutions in the UK.

Further Reading