Cross-functional team communication needs have increased significantly due in large part to the "Agile" software development process and its accompanying shorter build cycles. To overcome communications challenges, many organizations have implemented a Behavior-Driven Development (BDD) methodology for software quality assurance.
Using BDD during application development facilitates communication between business analysts, developers, QA engineers, and others on the application team because of the inherent "readability" of the documentation. Not only does BDD close communication gaps, it enables management to monitor changes and ensure they meet the product and business goals.
Applying BDD, business analysts work with product managers to capture the stories that will help identify the behavior; developers code from these stories, and testers write the scenarios that can then be automated.
BDD complements TDD in an existing project
Test-Driven Development (TDD) of the application requires writing test cases first and then developing the code. But TDD can produce a perceivable communication gap between the technical team and management which BDD can help alleviate by its use of the simple and structured language known as Gherkin.
Let’s take a look at a single feature of a mobile app involving chatting and sending a photo. Features are captured using Gherkin in an appropriately-name file called a .feature file. Gherkin follows a sequence of structured language blocks in the pattern "Given x, When y, Then z".
Feature: If the user sends a photo, they should be able to see its thumbnail view, and on tapping it a preview of the photo should be visible.
The expected behavior of the photo exchange feature in chat has been described using the steps of a typical Gherkin scenario:
As you can see, the Gherkin syntax is easily written by product managers and analysts, the developers can get a very clear idea of the business logic the code must support, and the QA engineers can translate the Gherkin into an automation test using a framework such as Capybara. If needed, there can be more than one Gherkin scenario to fully cover all aspects of the application feature.
Consolidation of test results in the form of a feature matrix
To keep the management apprised of the health of the project, QA engineers should use a feature matrix. Each application feature is captured and mapped to a corresponding scenario in the Gherkin script. As tests are executed (either manually or via automation), it's easy to capture and track results in this matrix. You could even automate the update of pass/fail results into this spreadsheet from an automation run - why not??
The following feature matrix displays the results of some features of a mobile app in the two primary mobile OS’s - Android and iOS. Just by glancing down the sheet, you can see what works in each OS and what doesn’t - for instance, the In Call Chat feature does not work on the Android OS.
In the fast-paced world of web app testing, the value of continuous and clear communication cannot be stressed enough. Although OnPath Testing is headquartered in Boulder, Colorado, we use engineers from around the world and rely on good process and methodologies like BDD to establish rock-solid communications with the wider team.
