Change Is Hard, but BDD Is Worth It
Given I think change is hard and scary, when I am faced with something new, then I won’t try to adapt my processes and improve my skill set.
If you’re familiar with behavior-driven development (BDD), then you recognize the given-when-then format of the above scenario. And if you’ve ever had to go through a major change, you can probably relate to the negative feelings associated with that process.
Change and adaptability are important, not only to keep moving our projects forward with better techniques and processes, but also for our personal and career growth. BDD is a methodology change that impacts the whole team, and unfortunately, it’s not as easy as writing a few scenarios in a specific format. My team has taken on the challenge of implementing BDD over the past year, and honestly, it’s been difficult.
If it’s hard and if it requires work, what is the added value of BDD? Why should the team throw their current process out the window and try to incorporate a new methodology? Wouldn’t it be more productive to keep working the way we always have and not have to stop and learn something new?
These are all questions my team has asked (and I’ve asked myself!) over the past year. Some days it feels like we are on the verge of doing something really amazing, and other days it feels like we’re at a standstill—and there have even been a few days where it’s felt like we’ve gone backward. But as we have worked our way through this process, we’ve learned a lot, and I believe that this challenge has been worth it.
Here are some ways our development team benefits from this improved process:
- BDD has provided us a way to revamp our team and get the most value from business analysts, manual quality analysts, and automation engineers, and it’s helped redefine roles in a DevOps world
- BDD is helping us get more to the heart of our business needs and ensure the entire team is aware of the use cases, therefore delivering a higher-quality product focused on what our customers need and want
- BDD has filled a void with our automation tests by providing living documentation that not only tracks what is being tested, but helps us “test the tests” when a test step fails
It’s not perfect. We haven’t mastered BDD yet. But we are working toward a change that has the potential to make a direct impact on the quality of our applications.
In addition to improving the way we work, each person on the team has grown and is learning the leadership skills that come with making a significant change. It hasn’t been easy, and sometimes it has felt scary, but the long-term benefits we will see from BDD are worth it.
This article was originally published September 20, 2019, on TechWellInsights.com.
Christine Fisher started her career as a high school history teacher, but a switch to software training got her started on a career path in technology, where she has held various positions in professional services and development over the past fifteen years. Currently managing a team of business analysts and software quality engineers at the National Association of Insurance Commissioners, she has found that her roots in teaching are still important to help build and develop a strong team. She's passionate about ensuring functional teams are equal members of the development team and helping define those roles as they change in a DevOps culture.