Over the past several years, many organizations have transitioned to Agile development in order to accelerate delivery and get more timely feedback from the market. In these organizations, while development begins to move faster, QA will struggle to keep pace unless they integrate automated software testing practices into the development pipeline, so that is often the first bottleneck to overcome.
But after successful adoption of test automation and the whole organization moving more quickly, organizations start to ask themselves if they are building the right software. Accelerating software development and ensuring software quality with automated continuous testing is a great achievement, but it’s all for naught if the software isn’t what your customers want or need.
Folks at this stage in their software development processes evolution are taking a close look at BDD as a means of ensuring that their software meets their organization’s business requirements. But what exactly is BDD and how does it pertain to testing?
BDD is an evolution of the test-driven development (TDD) methodology, in which developers write the test before writing the code. After crafting a failing test to start, developers practicing TDD write just enough code to ensure that the test passes, then write another test; rinse and repeat. The result is lean and mean code with high test coverage.
TDD is an activity designed to improve software quality and ensure code coverage. BDD, in contrast, solves the problem of correctly implementing requirements. Rather than focusing on the test to verify the functionality you want implement, BDD is about defining the behavior of the application so that it meets specific business requirements.
The similarity between TDD and BDD is that a contractual mechanism is implemented before any work is done, to ensure that the output matches a specific expectation. But this is where the similarity ends. In TDD, the test is a contract intended to ensure that the application meets a specific functional requirement. In BDD, the behavior is the contract intended to ensure that the application meets a specific business requirement.
We’ve been casually throwing around the term “behavior,” but it does have a technical meaning in the context of BDD. In BDD, behaviors are carefully-crafted, human-readable statements that follow a specific format. They are collected in “feature files” that can be integrated into the development process.
Feature files are typically written in Gherkin, which is a BDD-specific syntax that enables BDD tools, such as Cucumber and SpecFlow, to automate the process of validating the behaviors. These BDD tools parse the behaviors in the feature file and execute the appropriate “glue code.” This glue code maps “behaviors” to execution steps, typically Java or .NET test code written by a developer, in a specific test engine. These mappings are commonly referred to as ‘step definitions,’ or ‘step-defs.’ As a result, testers can use feature files as test cases that verify the behaviors associated with the requirements.
There are several advantages that Business-Driven Development brings to software development. With BDD, you can:
This last point is one of the key features of BDD. Modular, reusable test steps enable testers to rely on the BDD tool to do the heavy lifting when verifying and validating the requirements. The sticking point, however, is that developers are still required to write the glue code that binds the behaviors to the requirements. We’ll talk more about this next.
The biggest cost associated with implementing BDD is writing the glue code. In most cases, this task falls on the development team, which shifts the burden of creating the test artifacts for validating the requirements from testers to developers.
In a pre-BDD world, testers would use tools and frameworks to create tests that validate the functionality, not necessarily the requirements. With BDD, testers, business analysts, and other stakeholders define behaviors in a feature file, but developers or people with code-writing skills are still required to write the glue code that maps the behaviors to the functionality.
The fact that BDD adds to the cost of development can hurt organizations with limited development resources. Although the glue code is intended to be reusable and easier to leverage for test automation, the investment required to scale and implement BDD across the entire enterprise is often too high.
Parasoft helps reduce the technical burden associated with BDD test code creation and maintenance. There are multiple approaches to automated testing of an application chiefly amongst those are API testing and UI testing. Parasoft can reduce the technical burden for each in different ways;
Parasoft enables non-developers to write step-defs that execute as SOAtest tests, which greatly reduces the technical resources required to write tests. With the Parasoft SOAtest-Cucumber Executor, each step definition maps to a reusable SOAtest test or test suite that runs when that step is executed.
Consider the following examples:
Step definitions can also reference an individual SOAtest test or a test suite that contains a number of tests within.
Additional and unique technical challenges arise when integrating UI testing into your BDD solution. Similar to Parasoft’s API testing solution Parasoft Selenic has the ability to record UI actions from the browser and create pure Selenium code that can be associated with your step defs to drive UI test automation. To reduce ongoing maintenance of the pure Selenium scripts Parasoft Selenic creates Selenium tests leveraging the page object model. The page object model is a UI testing design paradigm where users can define UI elements in association with the pages on which they are present, This makes it much easier to maintain your scripts due to the element locations being defined in one place, and then leveraged across your test suite. As well as lowering the technical skills required to create the initial test scripts in the first place.
However, creation is a one-time cost and the majority of the burden incurred from BDD test code is in maintenance. Over time, as your application changes the element locators and wait conditions initially defined in the underlying Selenium test code may break. This causes confusion when reviewing test results because it’s difficult to determine whether your tests are failing due to real defects in the application or simple UI changes. This erodes the value that BDD provides.
Activated within your IDE, or, for CI/CD, with a one-line code change to your command-line execution, Parasoft Selenic performs runtime analysis of the test execution. When a test fails, it applies its AI heuristics to determine how that failure could have been avoided e.g., by updating locators or wait conditions), and then attempts to self-heal the test at runtime so that the pipeline can continue. You avoid wasting cycles debugging build failures due to unstable tests, and it learns more about your tests at the same time.
All of this reduces the time you spend maintaining, repairing, and fixing broken tests and allows you to reap the true benefits of BDD which is increased collaboration and increased confidence due to test automation.
Parasoft puts more control in the hands of testers and gives them confidence that they’ve completely covered the functionality under test. Leveraging a mature, feature-packed, end-to-end testing solution provides easy entry into test automation, test maintenance, and a natural integration into existing CI/CD workflows. At a high level, it enables organizations to leverage less technical resources to implement BDD, freeing up development resources, changing the creation area as illustrated below:
BDD is a powerful development practice that can ensure that the correct functionality is being built. Scaling BDD to the enterprise level, however, can be difficult because implementing the practice requires a large pool of technical resources. Parasoft lowers the technical barrier by enabling users to map behavior statements to step execution definitions using a simple to understand UI. The step definitions are executed as SOAtest tests, making it much easier for testers and non-technical staff to contribute to the verification process. Parasoft Selenic reduces the ongoing maintenance associated with UI testing through Selenic by providing AI generated recommendations for locators and wait conditions at runtime.
Contact us if you are interested in learning more about the Parasoft SOAtest-Cucumber Executor. Or request a free trial by clicking below.
Grigori Trofimov is a Solution Architect at Parasoft, providing consulting services for Parasoft’s testing solutions to prospects, customers, and partners. He has spoken at conferences recently on the topic of service virtualization and deployment of disposable environments in the cloud.