In this competitive digital era, the importance of software testing is well recognized and acknowledged. However, what to test, when to test, and how to test has kept evolving over time as we walk the progressive path of software development. Today, organizations must deliver high-quality software faster than ever before. As Agilists, we also strive to achieve business agility by reducing volatility, uncertainty, complexity and ambiguity. This task can be overwhelming in a world that demands the continuous delivery of quality products.
Using automated testing techniques is one engineering practice we can use to help us continually drive that quality with speed and efficiency; but how do we ensure we are writing effective test cases in the first place – test cases that validate that our applications are satisfying business expectations?
Believe it or not, it all starts with collaboration. Behavior Driven Development, or BDD, is an agile software development process that encourages collaboration in a software project between the IT team – requirements analysts, developers, QA, project managers – and the business team. The primary purpose of BDD methodology is to improve communication among stakeholders of the project so that each feature and related user story is correctly understood by all members of the team before the development process starts. This ensures the entire team is focused on quality, helps to identify key scenarios or test cases for each story, and most importantly, helps eradicate ambiguities from requirements.
The key to success is to shift test creation to the left or to the beginning of a project rather than creating tests after development is complete. BDD aims to help a project team flesh out user stories into detailed test scenarios that, when executed, will confirm whether the intended functionality exists and the associated business requirements are satisfied.
Developers implement the system using the tests – writing just enough code to pass the test scenarios. By continuously testing for the existence of a given functionality and writing code to introduce functionality that can pass the tests, developers’ effort is optimized to the point of just meeting the requirement. Additionally, tests and requirements become interrelated, always ensuring proper test coverage and eliminating or minimizing unexpected results.
The tests are specified in business domain terms in the form of plain English scenarios using the Gherkin syntax – Given, When, Then – created specifically for behavior descriptions. The business domain terms then form a ubiquitous language shared between the business and technical teams. This means that no development skills are required for creating tests. This promotes effective communication between both technical and non-technical stakeholders prompting early questions around whether the test scenarios are accurate and providing an opportunity to resolve the differences in points of view.
Now, although adopting a software development process like BDD does not require automation adoption, one of the greatest benefits it provides is streamlining test automation with tools such as Cucumber.
Cucumber, an open-source software tool, is a testing framework that supports BDD and is driven by plain English scenarios using the Gherkin syntax. Cucumber reads the code in plain English text and matches each step with an associated ‘step definition’, a code block that executes the Given-When-Then specifications against the system under test.
Cucumber allows us to utilize various testing tools such as Selenium, Appium, web service clients, database drivers, and many more, promoting full scope automation across the various interfaces that make up our software products. When we incorporate automation with BDD, we create a full-stack process that provides tremendous benefit and value: we collaborate, record that collaboration in some form of specification, and then automate that specification to drive the implementation.
Implementing an industry best practice like Behavior Driven Development (BDD) while incorporating automation is proven to provide the following benefits:
- Inclusion. BDD is meant to be collaborative. Everyone from the customer to the tester should be able to engage easily in product development. And anyone can write behavior scenarios because they are written in plain language. Scenarios are requirements for product owners, acceptance criteria for developers, test cases for testers, scripts for automation and descriptions for other stakeholders.
- Clarity. Scenarios focus on the expected behaviors of the product. Each scenario focuses on one specific thing. Behaviors are described in plain language, and any ambiguity can be clarified with a simple conversation or example mapping. There’s no unreadable code or obscure technical jargon, and there’s no game of telephone. Clarity ensures that business expectations are always satisfied.
- Streamlining. BDD is designed to speed up the development process. Everyone involved in development relies upon the same scenarios. Scenarios are requirements, acceptance criteria, test cases, and test scripts all in one – there is no need to write any other artifact. The modular nature of Gherkin syntax expedites test automation development. Furthermore, scenarios can be used as steps to reproduce failures for defect reports.
- Shift Left. “Shift left” is a buzzword for testing early in the development process. Testing earlier means fewer bugs later. In BDD, test case definition inherently becomes part of requirements grooming. Testing and automation can theoretically begin as soon as behavior scenarios are written.
- Quality-Driven. BDD is an evolution of test-driven development or TDD. Writing scenarios from the beginning enforces quality-first and test-first mindsets.
- Reusability. Given-When-Then steps can be reused between scenarios. The underlying implementation for each step does not change. Automation code becomes very modular.
- Momentum. BDD has a snowball effect: scenarios become easier and faster to write and automate as more step definitions are added. Scenarios typically share common steps. Sometimes, new scenarios need nothing more than different step parameters or just one new line.
- Adaptability. BDD scenarios are easy to update as the product changes. Plain language is easy to edit. Modular design makes changes to automation code safer. Scenarios can also be filtered by tag name to decide what runs and what doesn’t.
- Cost Savings. BDD also makes the software development process more efficient and effective overall, resulting in significant cost savings. BDD supports shortened test cycles, decreased defects, increased testing coverage and frequency, lower manual labor costs, and better delivery predictability, consistency, and continuity.
Following the full-stack BDD process, we end up creating software applications quickly and effectively that are not only well-built and tested but also what the business needs and expects. With BDD, software development teams can ensure they are constantly delivering high-quality software that matters.
