How to transition Agile teams to BDD model to Close the Gap

Over the years, the demand for faster software delivery has increased dramatically, forcing teams to adapt to new delivery models. Traditional processes have been modified and some were dropped all together, favoring the increase of constant communication amongst team members vs. extensive documentation. As the waterfall delivery model was slowly replaced with Agile approach, developers needed a way to start testing much earlier in the development cycle.

Let's take a look at some methods teams have used to integrate testing into the process, and explore a new way that focuses heavily on behavior.

Begin with Test Driven Development

Test Driven Development (TDD) has been a tremendous success in ensuring time is allotted for new feature code to receive appropriate test coverage. It was quickly adopted by agile teams across the globe. And while TDD solved a lot of problems, teams still struggled in a number of areas – specifically, gathering and interpreting requirements when given such a short time within a Sprint to complete this effort.

The process of decomposing, at times vaguely defined requirements and transitioning it into both code and test scenarios in the matter of a few days, is not an easy task. Team members often misinterpreted the desired behavior and implemented features incorrectly, which resulted in rework, carryovers to future Sprints and ultimately resulted in the late delivery of features to the client.

Introducing Behavioral Driven Development

This is when Behavioral Driven Development (BDD) was introduced. Teams were required to completely shift their mindset, changing the focus to concentrate heavily on desired behavior of the system while also encouraging more communication between key stakeholders. This change resulted in improved collaboration between customer representatives, QA staff and developers and ultimately, a much higher quality product and more tangible delivery deadlines.

BDD Style Requirements: Writing a traditional requirement is a very long and time-consuming process. To break a requirement’s acceptance criteria down into traditional test cases is an even more agonizing task.  In today’s fast paced, agile run projects, there simply is no room for additional requirement gathering process. This is exactly where the BDD process comes in handy, allowing the team to focus on the intent instead of documenting detailed requirements.

In a BDD world, product owners introduce new features from the system behavior perspective in the form of easy-to-understand scenarios that cover the expected behavior of the system. This is much more simplified model for easy interpretation by anyone on the team. The team will get together during “Three Amigos” sessions that will include a Product Owner, a Developer and a Tester to discuss the desired behavior further and drive to clarity. Each team member provides perspective on the new feature to ensure nothing is missed, confirming each member’s understanding is consistent, and explores the impact of the proposed change. This session answers the questions- are we building the right product? Are there impacts to other features because of this addition/change? Often, additional scenarios will come out of those discussions. But in the end, all team members will understand and agree to exactly what the ask is from the business’s perspective.

From Test Case to Gherkin: Writing test cases is a standard, but a very time-consuming practice for testing teams. Many teams are operating under assumption that it is still necessary to dedicate sprint time to cover new features with traditionally written test cases. These teams often continue to struggle to truly adapt Agile as they continue to push this traditional waterfall practice within QA groups.

In an effort to save time, many teams started transitioning to a “Gherkin” style acceptance test format – the same format BDD requirements are written in. With a set of common key words and phrases, when properly sequenced, can form a description of steps and desired outcome in an easy-to-understand format. Here’s an example:

Transition to automation

Once scenarios are finalized by the team, they can be transferred to a “Feature” file inside your chosen Integrated Development Environment (IDE) to be automated by either developers or test automation engineers. When ready, an automation engineer can convert previously finalized scenario steps into a coded test method. This ensures full coverage of the requirement by the automation code. It’s that simple.

Living documentation

As mentioned above, scenarios are grouped in feature-related files. These files should be a part of regular code check-in procedures, so the code base contains all the latest changes for source code and the accompanying test coverage components. This is a great way to keep track of changes and scenario content in synch, but what about those on the team who does not have access to the source control repository?

To address that, practitioners of BDD have created a mechanism that produces feature file-based reporting. The original reporting utility was called “Pickles” reporting and it could be used across multiple technologies and programming languages. More recently, Azure DevOps started using the same approach with the introduction of the LivingDoc extension. The extension provides a number of parameters including an ability to choose the output format like Word, PDF, HTML and the ability to set the output location providing the ability to easily and consistently update a shared file storage location that team members can easily access to gain insight into updates.

Ideally, the ADO project’s CI/CD pipeline(s) would contain an action step to trigger a report generating utility like LivingDoc so that no manual intervention is required. Reports are nicely formatted and accessible for everyone on the teams. it is always up-to-date and what we call "Living."

Transition to automation

Once scenarios are finalized by the team, they can be transferred to a “Feature” file inside your chosen Integrated Development Environment (IDE) to be automated by either developers or test automation engineers. When ready, an automation engineer can convert previously finalized scenario steps into a coded test method. This ensures full coverage of the requirement by the automation code. It’s that simple.

Living documentation

As mentioned above, scenarios are grouped in feature-related files. These files should be a part of regular code check-in procedures, so the code base contains all the latest changes for source code and the accompanying test coverage components. This is a great way to keep track of changes and scenario content in synch, but what about those on the team who does not have access to the source control repository?

To address that, practitioners of BDD have created a mechanism that produces feature file-based reporting. The original reporting utility was called “Pickles” reporting and it could be used across multiple technologies and programming languages. More recently, Azure DevOps started using the same approach with the introduction of the LivingDoc extension. The extension provides a number of parameters including an ability to choose the output format like Word, PDF, HTML and the ability to set the output location providing the ability to easily and consistently update a shared file storage location that team members can easily access to gain insight into updates.

Ideally, the ADO project’s CI/CD pipeline(s) would contain an action step to trigger a report generating utility like LivingDoc so that no manual intervention is required. Reports are nicely formatted and accessible for everyone on the teams. it is always up-to-date and what we call "Living."

How this helps your team

The BDD process will not solve every problem on an agile team, but it is a proven framework to enhance communication within a team, contributing to higher quality releases. Generally, adopting the BDD process is not difficult with proper coaching and diligence; and as the practice matures, teams will start to see the benefits quickly.

You can start your BDD journey by transitioning to this plain language approach and instating the “Three Amigos” sessions. Once your teams transition to this quality-first approach, concentrating on behavior of the system and close collaboration of cross-functional teams early, reinforced by BDD process, you will notice improved continuous delivery, reduction in bug numbers and unwanted surprises, and the ability to naturally transition to the Shift-Left approach.