.png){kind=icon}
What is Behavior Driven Development?
Behavior Driven Development (BDD), simply put, is a framework for software development that encourages better communication between all team members and stakeholders to achieve more effective results. Since the focus is on the behavior of a product, the entire team can more easily understand, in the simplest terms, what the expected results of these defined behaviors should be. In Behavior Driven Development, team members across all stages of a development lifecycle strive to speak the same language–a more “common code,” so that both highly technical stakeholders and non-technical team members can more clearly understand one another. Since effective communication is the main goal of Behavior Driven Development, the team is able to more intimately understand the desired behavior of a feature, the results all stakeholders are invested in, and how to achieve those results.
A comprehensive understanding between all members of the team also helps bridge the gaps between stages of a development cycle; by speaking the same, common language, the development team can more clearly establish the desired outcomes of a product or service to the quality assurance team, so that they can they more effectively test the product for bugs or defects.
Some major benefits of a behavior-driven development model include:
- Accessibility: Since the main drive of Behavior Driven Development is collaboration between all members of a team, anyone is able to engage with the process and bring specific knowledge to the table
- Automation: A behavior-driven approach makes the process of developing automation much more streamlined; since the desired steps and outcomes are already plainly defined, writing code to automate is simplified
- Adaptability: Behavior Driven Development allows a development team to easily edit or modify along the development cycle to address changes in features/desired outcomes for the customer
What does BDD look like?
The greatest benefit of Behavior Driven Development implementation is that it describes, in an unambiguous way, the exact set of behaviors and desired outcomes of a product or application. From start to finish, this model allows all members of the team to utilize their specific knowledge more effectively, since they clearly understand each set of behaviors that are expected.
Let’s take a look at how Behavior Driven Development “common language” is established and structured, to more or less be in plain English among the team members. Behavior Driven Development helps to facilitate this communication to your testing team so that they clearly know what the desired outcomes are, and what defects to look out for.
Behavior Driven Development cases are written in three main sections, forming a Given-When-Then structure:
Context: The beginning or starting state (“Given” statements)
Event: What the user does (“When” statements)
Outcomes: What results are desired (“Then” statements)
Given a user is on the login screen
And they enter a valid username
And they enter a valid password
When they press the login button
Then they should see the login successful page
Since a Behavior Driven Development approach allows for this style of communication, business people can focus on describing the issues and things that matter most to their customers in such a way that developers and quality assurance testers fully understand what is expected.
When should Behavior Driven Development be used?
Approaching testing with Behavior Driven Development in mind allows for developing tests at any stage in the development cycle, making it much easier to address last-minute changes or bumps in the road along the way.
From the beginning of the entire development lifecycle these behavioral benchmarks have been established, so developers have a framework for writing code and what will be the expected outcomes all along the way. A problem can arise, however, in behavioral testing versus unit testing, in that behavioral tests may not always indicate what, exactly, the problem is. In our above example of a behavioral test case, our behavioral test would only fail if the user was not shown the login successful page after completing the needed functions. In this event, the behavioral test would only indicate that there was a problem, whereas a unit test in isolation would identify exactly why the user was not shown the successful login page. While behavior-driven development models may function in much more plain terms with an end goal in mind, unit testing and testing in isolation may be needed to identify the specifics of any bugs found.
Comparing Behavior Driven Development and TDD
Behavior Driven Development can differ from traditional unit testing, in that it may take a longer period of time to truly complete an entire behavioral test, so careful attention to planning the lifecycle of a project is important. Unit testing is, by and far, much faster to complete than Behavior Driven Development testing, but a “shift left” (that is, beginning testing early on in the development process) can also be a benefit in finding more bugs early on with the plain English cases.
In unit testing, where most tests are written in technical language and code, the developer is responsible for writing cases that ensure the code simply functions. In a Behavior Driven Development model, however, behavioral test cases are best written by the team members who likely understand their customer the best–usually the product owner and business/development team. Further, since behavioral testing is driven by the end goal for the user, the quality of testing can benefit greatly from a slightly longer timeframe. Another difference between behavior driven development and test-driven development is the accessibility of information to all members working on a project. In a traditional test-driven development format, it is likely that only the developers and testers will be reading and working with the test cases; in behavioral driven development, on the other hand, most anyone can read, understand, and give feedback on development and testing-–from the product owner, the business owner, or any other outside stakeholders.
Finally, since Behavior Driven Development focuses on specific sets of behaviors, it is much more well-suited for functional and black box tests such as APIs and webUIs. On the other hand, performance testing–where very specific, detailed information is needed–may be better accomplished with traditional TDD testing.
Behavior Driven Development and test-driven development both have their benefits when it comes to QA testing. Our experience with both frameworks allows us to provide guidance on what works best for you. At PLUS QA, we’re here to help, regardless of your testing needs. Please feel free to reach out to us with questions and inquiries!