Can you use BDD for legacy applications? Sure you can!
A few folk have been asking me about how BDD works with legacy applications. So here are my thoughts.
BDD is a collaboration process that involves multiple team members working together with BAs, business or product owners to discover and refine requirements using structured conversations about examples of user and system behaviour. It is an extremely effective way to increase shared understanding within the team, and as a result reduce defects and accelerate delivery.
And, for legacy systems, one of the biggest challenges is often not just understanding what a feature needs to do, but understanding what the current system does. BDD gives us tools to challenge and explore our assumptions about how the system works. And it gives us a very effective way of documenting our understanding about the system.
When you automate these examples, they become “executable specifications” and “living documentation”. But automation is not the primary goal of BDD - automation is a means of accelerating feedback and keeping you focused on delivering the essence of the feature without being side-tracked.
I work with teams routinely to help them introduce BDD practices, and it is rare to work on totally new applications. Most teams work on existing applications But the benefits of good BDD practices are still very tangible, and the same requirements discovery techniques (such as Example Mapping and Feature Mapping) are still very effective.
BDD helps us identify key examples and business rules that capture the essence of a requirement. For legacy applications, the examples and executable specifications document how a new feature should work, but they can also give a broader picture of how the existing system works. This gives the new feature (or change request) context, documents the team’s understanding of how the legacy system works, and adds valuable regression tests to boot. As legacy applications are generally poorly tested, this is a great bonus.
Automation plays an important supporting role in a BDD process. Automating the acceptance tests for a legacy system can be more challenging than for new applications, and often needs changes to the existing code base. It will inevitably involve some initial planning and design, but the time spent doing this pays for itself very quickly when your acceptance tests become easier and faster to write, and possibly faster to run as well. This is harder with vendor products, but generally very doable for internal applications.
So don't go thinking BDD is just for new projects!:
