Building data integrity in the public sector
Optimize your spend by adopting a comprehensive data testing...
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.
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:
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.
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:
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.
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.
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:
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:
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:
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:
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:
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.
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.