Overcoming the Real Fears behind Behavior-Driven Development

Behavior-driven development is one of the hottest trends in the testing industry today. It promises greater collaboration, increased automation and test case reuse, and less documentation and waste, just to name a few benefits. It is increasingly seen as the perfect complement to agile delivery and planning processes, and the readability of the tests makes it a great counterpart to DevOps, continuous integration, and continuous delivery, too.

Then why have only 10 percent of respondents to the 10th Annual State of Agile Report said they’ve tried this technique?

To understand the reasons companies are not employing BDD, it is important to understand some key characteristics of BDD that make it different from other development styles. Some of these differences typically include:

• Frequent, in-depth collaboration among developers, testers, product owners, and business analysts
• Teamwide ownership of quality, related not just to creating and running tests, but to the application as a whole
• Defining software performance criteria based on specified tests with discrete outcomes, rather than typical prose
• Employing automation from the beginning so that tests can be run multiple times without much manual overhead
• Following a cycle where the test is created before the code and the code is written against the running test (usually automated) until it allows the test to pass, at which point the feature is refactored but not embellished

In The State of Test First Methodologies report, the number one reason organizations gave for being fearful of implementing BDD was actually not due to new automation tools or technical challenges involved in the implementation; it was related to the characteristics given above. The greatest fear they cited was getting developers to collaborate and own the quality of the application.

Companies say they are concerned about getting developers to work in “Three Amigos” sessions with the testers and product owners, following best practices around code reviews and check-ins, and creating more testable software with accessible APIs and consistent, readable logging.

As has been the growing trend, the lines between testing and development are becoming more and more blurred. As teams shift toward more automated testing approaches, everyone on the team is expected to have some technical knowledge to contribute. On the flip side, as more companies remove the layers of human abstraction between developers writing code and its reaching the end customer, developers are expected to have a greater grasp on quality and how to test their application.

While it’s far easier to evaluate tools and customize frameworks in a search for improved software delivery, the tools can only achieve as much as the people and organizations behind them. We all shy away from introspection at the personal and team level, but often, the greatest opportunities for improvement lie with us and our daily interactions with our teams.

To implement a new development process, whether it is BDD or otherwise, do not focus on tools alone. You also have to consider the critical importance of our individual roles and personalities in our development successes and failures.

Kevin Dunne is presenting the session Making the Move to Behavior-Driven Development at STARWEST 2016, October 2–7 in Anaheim, California.