Unlocking the value of tester-developer collaboration

In the era of digital transformation, misalignment between the business leaders steering the overall strategy and the technical experts who build, implement, and maintain solutions is one of the top blockers to a successful sea change.

These groups need to be able to collaborate to define what each solution requires and the why behind it. Behavior driven development (BDD) is an approach to testing that emphasizes collaboration between business users, developers, and testers at crucial points in your development process.

No matter the framework your organization is using, you can still implement aspects of BDD into your processes to facilitate continuous testing, maximize risk coverage, identify issues faster, and nail the perfect product sooner.

The broad strokes of BDD

We all know this main bellyache of traditional workflows – the business needs of the stakeholders get lost in a game of telephone tag between siloed workers. Core requirements and critical functionality get lost in translation from group to group, leaving issues and errors to be discovered in the final stages of testing where they are more labor intensive, expensive, and tedious to correct.

A BDD workflow incorporates communication across teams at earlier stages in the development process.

It might look something like this:

1. The stakeholder and the product owner discuss the business need and its various ins and outs.

2. The product owner, developer, and tester (the “three amigos” in BDD parlance) collaborate to determine exactly what will be created and how that solution will support the business need.

3. Together, they produce requirements that are easy to understand. Requirements are written using BDD’s Given-When-Then scenarios (aka Gherkin).

4. The tester uses these agreed-upon scenarios to create automated tests. The developer uses them to create code. Automated tests gauge the build’s features against these scenarios and document traceability.

This workflow helps eliminate silos and miscommunications. The stakeholder and product owner both give input; the product owner isn’t simply an order-taker for the stakeholder. When the developer and tester work from the same playbook (the agreed-upon scenarios), tests will more faithfully reflect and support the required functionality.

Marrying BDD and TDD practices

Test Driven Development (TDD) stands as a pre-requisite to BDD, as it introduces testing earlier by creating unit tests before code. This is intended to test the required functionality at the beginning of the development stages, ideally delivering the desired functionality in production.

A few things to note:

• While TDD more closely ties testing with the requirements, BDD helps tie requirements to the business need.
• While TDD primarily describes how the functionality will be implemented, BDD describes how the application will behave for the end-user. According to Digital.ai’s 2020 State of Agile Report, around one-third of companies use test-driven development (TDD), with only 19% performing BDD.
• BDD prescribes when development should begin, what should be tested, and how those tests should be structured and named.

Testers may balk at this framework of development, as they think it requires them to write more tests than they normally would. In reality, BDD helps testers identify the most impactful tests and scenarios, reducing wasted resources and giving time back to other business-critical tasks.

Assessing your BDD maturity

At Tricentis, we’ve seen a few patterns emerge among our clients seeking to adopt BDD. We’ve used this knowledge to create a five-level framework for understanding your team’s progress.

By assessing your current maturity, you can determine incremental steps for your team to evolve toward BDD maturity — after all, BDD isn’t about technology, it’s about people.

Level One

At Level One, your team is taking its baby steps into the BDD philosophy. The team’s goal in Level One is to make collaboration work across all team members. For this to happen, the roles of product owner, developer, and tester need consistency and definition in the part each plays in the Agile environment.

For now, the “three amigos” will work together to explore the needs of the business and design acceptance criteria to support those needs. At this level, they need to understand the business goals enough to interrogate the form and validity of the features being asked of them.

Your team will begin documenting in the Gherkin style. Though your team is familiar with the concept of living documentation, they haven’t received any formal training to write in the Gherkin syntax. Doing so will take some practice.

Don’t worry about choosing frameworks and tools yet. It’s perfectly fine for your team to write acceptance criteria and scenarios on notecards or notepads.

You’re ready to move to Level Two when:

• Collaboration and alignment are improved with early sessions between the product owner, developer, and tester.
• Example mapping sessions demonstrate visible progress and help gain exec-level buy-in.
• Your team is highly focused on making sure the foundational building blocks of BDD are in place.
• Your team is writing Gherkin-style scenarios, though proper use of Gherkin syntax is sporadic.
• User stories are clearly related to business outcomes.

Level Two

Now that your team has felt out a few BDD processes, it’s time to choose a tool to tie those processes together. SpecFlow, Cucumber, JBehave, and Gauge are a few reliable candidates.

Whichever tool you choose, your team will adopt that domain-specific language. They will also learn and familiarize themselves with the Gherkin syntax structure. This sets the foundation for more effective TDD and test automation.

You’re ready to move to Level Three when:

• New user stories are implemented with code and automated tests are written.
• The proper Gherkin syntax is familiar to all team members, and Gherkin concepts like feature, background, and databases have been introduced to improve test writing.
• You’ve chosen BDD tools.

Level Three

In Level Three, you’ll connect your BDD tools to project management tools (e.g. Jira) and source code (i.e. Git).

By connecting to the source code, developers can use test scenarios to drive the implementation of the feature. Meanwhile, testers can execute the test scenarios that validate the defined behavior and drive automated deployments.

By connecting to project management tools, you can provide traceability for sprint progress.

You’re ready to move to Level Four when: 

• Features are stored with source code, serving as a single source of truth.
• Features status helps progress issues into production members.
• Results and statuses have been rolled up to the overall project plan for acceptance criteria.

Level Four

Most organizations stall in Level Four because their QA teams stop short of adding automated step definitions. Instead, they simply run their scenarios manually after development has implemented the feature.

Automated test scenarios are a must to achieve true BDD maturity.

At Level Four, your QA team should marry their BDD testing processes with the development team’s TDD processes.

Once the feature has been created, teams should generate automated code stubs that send failing step definitions into a Git repository. Since the code repository is connected to the CI pipeline, the team can’t progress until they add test automation and ensure the automated tests pass.

Finally, your team should include exploratory and usability testing after test scenarios have been automated.

You’re ready to move to Level Five when:

• You’ve mastered TDD as part of your BDD process.
• Feature file results are reported back through the CI pipeline for full continuous integration.
• ChatOps workflows instantly alert team members when results fail.
• You’ve added a proper mix of exploratory testing to your test cycle.

Level Five

As with most maturity models, this final level concerns reporting on BDD progress. With insight and clarity, you can refine your processes and extend your BDD practices to new teams and business units.

Engineering teams need to know which scenarios passed, which ones failed, and the overall pass/fail rate.

DevOps managers will need traceability reports to understand which features are ready to be pushed to production.

Executive business leaders need to know the risk profiles, time spend, the average number of test scenarios per feature, and the overall automation progress.

You’ve fulfilled Level Five when:

• Your real-time pipeline analysis accurately indicates the current state of business value delivery.
• Phase analysis details why certain handoffs are speeding up or slowing down.
• You’re using retrospective views to summarize data for review after the completion of a sprint or major release.

A BDD success story

Specsavers is one of the largest providers of glasses and contact lenses in the UK, and they are expanding across Europe, Australia, New Zealand, and online.

Specsavers applies a BDD approach to its digital web-CD pipeline and digital API-CD pipeline, automating key coverage journeys and functional regression testing. The company chose the open-source Serenity BDD framework because Serenity stores the Given-When-Then scenarios in the output. This allows the Specsavers QA team to see which step the test fails at, speeding up defect diagnosis.

Most importantly, the greater automation coverage afforded by a BDD approach allowed Specsavers’ manual testers to perform higher-level work. By automating repetitive tests, manual testers were free to perform more exploratory testing. This allowed them to become much more effective at finding defects when compared to performing scripted tests. The Specsavers team uses the Sessions feature in Tricentis qTest to record these exploratory sessions so that issues can be documented and recreated.

With this workflow, it takes the Specsavers team only 16 minutes to run the necessary test cycles to achieve 92% test coverage.

Keeping the main thing the main thing

Dan North, one of the creators of BDD, describes BDD as “using examples at multiple levels to create a shared understanding and surface uncertainty to deliver software that matters.”

Even if your organization isn’t chasing a strictly BDD approach, there are lessons and strategies you can adapt to your own processes and teams.

That’s because BDD isn’t about tools or technology. It’s about making the right thing and arriving at that right thing much sooner through collaboration, communication, and clarity.