How Behavior-Driven Development Can Help Your Engineering Organization Shift Further Left in Agile Development

How Behavior-Driven Development Can Help Your Engineering Organization Shift Further Left in Agile Development

Adoption of Agile practices has become the overwhelming choice in today’s software development organizations.  Agile is iterative in nature as it requires repeated short cycles of the traditional waterfall process. Agile is great for shifting left to greatly improve quality.

“A core goal of Agile is to meet the dynamic needs of the customer. The Agile model also aims to improve visibility, increase efficiency, engender collaboration, and allow for the ability to nimbly change course.

It is generally accepted that over 80 percent of software projects participate in Agile practices.  Although behavior-driven development (BDD) is in its infancy, it has gained tremendous traction in the past two to three years.

This 2019 article by Lisa Crispin shows that 36 percent of teams are participating in some form of BDD/Test-Driven Development (TDD).  Moreover, Smartbear’s recent article on Cucumber indicates that some teams’ defect rates drop significantly over time using BDD, up to a 90 percent reduction.

“BDD extends Agile by specifying the behavior of the system with examples before any code is written.  Development is completed when the specified behavior is satisfied.

What is Behavior-Driven Development?

BDD is an Agile software development practice designed to enhance COMMUNICATION among software engineers, quality engineers, product managers, business analysts, customer success, system integrators, and business stakeholders.

BDD is a COLLABORATION framework focusing on the behavior of the application from a business user’s perspective.

Why BDD?

  • Higher quality product
  • Version-controlled executable documentation
  • Strong agreement of requirements between development and product
  • Clear acceptance tests for satisfying business needs
  • Reduction in re-work due to unknowns or assumptions
  • Greater visibility

Key Phases of BDD

Discovery – Conversation to scope what is being developed.  Business rules are discussed and questions are asked to clarify the desired behavior.  Real-world examples describing the desired behavior are created.

Formulation – Examples created from Discovery are translated into structured documentation that adheres to Gherkin.  The examples are transformed into Scenarios that can be executed by Cucumber.

Automation – Scenarios that were created during Formulation become executable in this phase.  The code that performs the interactions with the application are created based upon the Scenarios.

Story Mapping

Story Mapping is a technique to assist in visualization of work to be completed.

  • 2D visualization of the product backlog
  • Key Activities/Epics are displayed in chronological order (purple boxes)
  • User Stories (green boxes) are planned for sprints

Story Mapping example:

Conclusion

Although we are still in our early adoption of BDD, we have already seen improved collaboration and a reduction in re-work for participating teams.

Curious about the specifics of how we implement BDD in its three phases?  Read our April blog post as we dive into the specifics of Discovery by utilizing Example Mapping for BDD.


Mark Rachwal, a Limelight Health QA Manager with a software engineering background, is passionate about Agile testing. He enjoys working with his fellow engineers to expand the testing tools available in their toolbox. “Nothing is more satisfying,” he says, “than bringing different people together to strive for one common goal.” In his spare time, he coaches kids in sports to not only help them become better athletes but ultimately become better people.
Send this to a friend