Recently I have been working with my two scrum teams to implement a BDD approach to our development. I’d have to say that the early results are astounding! While I have always known and believed in BDD in theory, I continue to be amazed by its simple power in practice. For anyone reading who is considering BDD adoption, below are 10 good reasons to move off of the sidelines and embrace BDD:
1. Communication between business and development is extremely focused as a result of common language.
A recent scrum team I lead was struggling during groomiing sessions to come up with valid acceptance criteria. After much excruciating pain we introduced ubiquitous language of BDD. What was taking days was accomplished in just a few hours with better quality forged from increased understanding of expected behavior.
2. Business needs tie directly to the code that is written.
The scenarios can be written by the business, testers and/or developers. Since the scenarios can be written by business and the scenarios create the tests, the code that satisfies the tests satisfies the business requirements. Simple.
3. Developers know what test cases they should write to accommodate TDD.
Most developers will see the wisdom in Test Driven Development, but they find it very hard to decide what tests to create. BDD eliminates this by having tests created directly from scenarios, making the process of deciding which tests to write a moot point.
4. All the underlying benefits of TDD become more easily realized.
These include: safer refactoring, fewer regression defects, greater ability of QA to concentrate on important tests, defects are found and fixed sooner.
5. Code is easier to maintain.
Studies have shown that about 90% of investment in software involves the maintenance of code after the initial “project” is complete. BDD means that all features have tests and these tests show how the code is used and make the code easier to understand and maintain.
6. Code is self documenting.
Similar to the point above. Your test cases and scenarios become your documentation. Using BDD will allow you to have updated documentation that is not separate from code, but integral to code. Documentation can be easily extracted and that documentation is understandable by anyone.
7. Stories are easier to “groom” – breakdown, task and plan.
I can better estimate a story that I have acceptance criteria for and the BDD scenarios become that acceptance criteria. Armed with the scenarios ahead of planning allows a team to better understand the work needed and estimate how long it will take to complete.
8. Teams can be more agile.
Like the point above – when your requirements are better understood, your acceptance criteria better known and estimates more accurate you can be more agile.
9. Developers can be trained / on-boarded easier.
Since the code is self-documenting and test cases show how the code should work, new developers have access to a wealth of information that is usually not available when they are brought on-board a project. This point alone should be a driving reason to adopt BDD as new developer training is usually steep.
10. There is more visibility into team progress and status.
One of the main benefits to Agile is to have visibility into team progress. The tasks for completing a story are broken into well-known pieces that burn down cleanly. For example, each scenario can be added to story as a task and tracked to completion to see how well the story is progressing.
I hope that you find my reasons compelling and that you too try BDD and see if it provides the benefits I outline.
– Larry Apke
