B is for “Business”

jonathan-blog

Bringing IT engineering closer to “The Business”, one of the principles of Agile, is something we keep talking about. You’ve already heard about how Scrum teams have a “Product Owner”, (usually a person from Marketing) totally devoted to translating real business needs to IT teams (usually developers), to produce and deliver valuable “stuff”.

In the real world however, Business people and IT folks just don’t speak the same language. I’ve been there as a “Scrum Master” and let me tell you: what makes perfect sense for a Marketing Analyst is ancient Greek to a JAVA developer. The whole promise of Agile is in danger of falling apart from the onset, because here I am trying to mix people from entirely different backgrounds and aspirations. Bringing the Business and IT together? Sure…

How do you get a developer to communicate (in intelligible sentences) to a CMO? How does a Digital Marketing Lead discuss requirements with an e-Commerce platform architect in something that makes sense from the very first minute? How do product owners, developers and testers able to collaborate when they come from such disparate backgrounds?

The answer is something called BDD.

In a previous blog post, we spoke about the value of implementing a Test-Driven Development (TDD) approach in complex and uncertain projects. Teams that implement “TDD” begin their engineering process by defining all the possible conditions and quality criteria by which a feature will pass testing: Acceptance Criteria and Test Scenarios. Once these test scenarios are complete and fully understood, engineers know what to build upfront and can begin work accordingly.

Test-Driven Development has been out there for a long time, and as we mentioned before it’s really nothing new, but in the past few years an extension of this approach has been proposed, coined “BDD” or Behaviour-Driven Development.

At its core, BDD tries to extend TDD by writing the acceptance tests around usage and the system’s behaviour when used in different conditions. BDD is a methodology in which we explicitly write our test scenarios in English and around the user (a bit like a User Story).

The generic language of such scenarios looks like the following:
Given that some pre-requisites are met, that a background is set
When a specific action happens,
Then some specific result is achieved

We refer to this as “Given-When-Then” test scenarios.

Forget behaviours and User Stories, fuzzy concepts I’m still trying to get my head around. What we have here is a clear way to write, communicate, visualise, and define how “something is supposed to work”. Test scenarios translate requirements and acceptance criteria in a cohesive way using an ubiquitous language. Suddenly your requirements make sense to everybody.

I once heard someone call it “Business-driven development” and it’s exactly what this is all about. BDD allows Business Analysts, product owners and other members of “the Business” to explicitly express how the feature is meant to work under all possible conditions. Sure, test scenarios are then enhanced by QA experts and technical teams, and a proper refinement process will involve all parties to make these as complete as possible. But at least we have a unified way of defining how a system is meant to operate.

Moreover, these scenarios can be initiated by simply writing examples of what the system is expected to do:

Given that a customer has bought a black sweater
And we have 12 black sweaters in stock
When the customer returns the black sweater
Then the stock should be 13 black sweaters

…easy.

Now comes the best part of this BDD methodology: these are not just scenarios we write as a communication tool. These are the tests. These bits of Given-When-Then scenarios are engineering tests. It all looks like plain English, but it’s code, and now engineers can use JAVA- or JS- or Python-based testing frameworks to check and validate that functionalities works as expected, in all the conditions defined therein. Modern development practices set forth by Extreme Programming advocate for the use of automated regression testing suites: every time a new feature is added to an existing system, automated regression tests are run against all previously written scenarios to ensure we haven’t broken any existing functionality. BDD testing frameworks are typically used to do this, and are useful in Agile projects where we build products incrementally, adding feature on top of a feature.

The beauty of it is that product owners, testers, architects and developers all contribute to writing something that not only ensures a common understanding of how features are meant to behave under all possible conditions, they are all writing code that is used in the engineering pipeline to pass testing. They’re all doing QA.

The “Given-When-Then” way of writing tests is now mostly referred to as Gherkin, made popular alongside Cucumber, a testing framework which has gained massive popularity in the past years. BDD has spawned a number of testing frameworks such as Behat, Robot, and Jasmine amongst others (the list keeps growing).

Now, some lightweight engineering is needed when implementing a BDD approach. BDD frameworks require some thinking, some work, and a specific process within the team to produce complete automated test suites, but once you have one in place, it’s a breeze, and all parties feel involved. BDD is referred to as an Agile “testing framework” but it’s much more than that. It embodies a coming together of people seeking to deliver what’s right the first time around.

By Jonathan Lhrar