How BDD can improve business-developer alignment

operations aligns with business
Thinkstock

Developers, testers, product managers, business managers, and users often have different viewpoints on what makes great software. This can lead to bottlenecks and unnecessary rework, which adds cost and frustrates those in charge. Ultimately though, software must fulfill the expectations of the user/customer and meet business objectives.

That’s where behavior-driven development (BDD) comes into play. This development methodology was born of the need to put desired behaviors of a feature first, and BDD tools and processes help keep all the stakeholders on the same page using plain English.

A quick rundown of how BDD works

Unlike traditional development unit or functional test scripts, BDD scripts are written in the form of real-world use case scenarios using the Gherkin “Given-When-Then” syntax that is used by popular BDD tools like Cucumber.

Here’s an example:

Feature: Sign in

Given that I have an [SITENAME] username and password

I should be able to sign into [SITENAME]

If my username and password are correct

Scenario: Enable password reset

Given I have signed up for [SITENAME]

And I have never logged into [SITENAME]after 90 days

When I press enter my username and existing password to login

Then I should be notified and prompted to change my password

Anyone from engineers to product owners can write BDD scenarios, because they are in layman’s English. The desired behavior is documented in the feature file and tests are automated to validate business scenarios you want to create.

At a high level, BDD forces stakeholders to work together because the entire team is tracing their tests, code and acceptance criteria to the feature file. For instance, when a test fails, the developer should agree that it’s failing because it doesn’t match the behavior of the system that’s being developed. BDD focuses on speed and quality, the latter of which has been a weakness of devops. At its best, BDD eliminates finger-pointing when something goes wrong during development or postproduction.

BDD was born out of test-driven development (TDD), which is all about unit testing. BDD takes TDD to the next level by focusing on scenarios and user experience, in addition to verifying that the code is working properly and doesn’t break other code in the branch.

Business benefits of BDD

BDD is great for developers because scenarios focus on how the feature should behave for the user, which means less ambiguity in what to develop. Another key benefit is that it’s easier to turn these scenarios into automated tests using the Gherkin syntax. How the business benefits has been discussed less frequently, but is equally if not more important.

1. Maximize resources and minimize waste

Business stakeholders worry about competitive moves that can upend revenue growth or turn away customers. Therefore, when it comes to working with the development team, business folks want to increase speed to market, while delivering a truly awesome user experience. BDD isn’t a silver bullet, but it does limit the rework of a feature because BDD tools (like Cucumber) enable a cross-functional team to easily and clearly define the user experience at the beginning of the devops cycle. This helps focus the project and prevents the introduction of features that aren’t relevant to the user base. BDD also speaks to the speed component in two ways: by preventing bottlenecks and by decreasing manual testing.

2. Improve communication to achieve shared goals

Devops set out to improve development processes to be more collaborative, streamlined and fast. Still, much is left to chance when it comes to communication and collaboration between different roles. BDD encourages more test automation and a process that is inclusive of non-developer employees. What’s cool here is that, while the “three amigos” process focuses on collaboration among a tester, developer, and product manager, BDD could include other roles too, like a business analyst or QA lead. Having more cooks in the kitchen with diverse perspectives can ensure alignment at the outset and ultimately produce higher quality software, especially with a high-stakes or complex project.

3. Deliver high-quality software that meets the desired business outcomes

Quality is a subjective term. What BDD brings is explicit agreement on this notion of quality, among people from sometimes opposing spectrums of the product life cycle. BDD supports increased automation, which increases testing speed and coverage, but never loses sight of the acceptance criteria or the initial product vision.

While it’s never easy to shift to an entirely new process, we at QASymphony have seen the adoption of BDD pay off for a number of companies. One I know was able to minimize defects and speed time to market after switching to BDD. This company’s QA team struggled with defining the correct test scenarios based on the business requirement, since QA, developers and product owners were never brought together in sprint planning sessions when user stories were written. The testers often didn’t even see them until development had begun.

Now, testers attend every sprint planning session, and they’re able to write test cases alongside product owners and developers. Not only does this ensure product owners can see developers’ and testers’ interpretations of requirements and correct any misunderstandings in real time – the whole team also spends their time much more efficiently, because they’ve all agreed upon what to develop in advance. And because they’re using a BDD framework, the scenarios they test can be easily translated into test automated test scripts, which saves significant time in the testing process.

This article is published as part of the IDG Contributor Network. Want to Join?