GASPAR. ROSE NAGY (SEB.) - BDD BOOKS - DISCOVERY: Explore Behavior Using Examples

BDD is an Agile approach to software development that insists that detailed requirements for a feature should be defined collaboratively by the business and delivery teams. The output of this collaboration is documented using business terminology that can be understood unambiguously. Finally, the documentation is structured in a way that enables it to act as automated tests that verify that the system behaves as intended. This book explores, in detail, the collaborative aspect of BDD.

BDD has been proven to be successful in thousands of projects around the world, on different platforms, in diverse industries and various project sizes. BDD is based on a set of practices that originate from the experience of many people over many years, working to uncover better ways of delivering software. However, there is a learning period (or, more accurately, a practicing period) for BDD, so it will take some time before you start seeing a return on your investment.

We belong to the second generation of the software industry (we could call ourselves Generation Y there are a lot of similarities). We don't believe in buzzwords or well-named methodologies, but we like to try them out to see whether they work. So, if you try out BDD, how can you decide whether it has worked or not?

The first indicator you are likely to notice is a reduction in cycle time. The shared understanding that is gained during collaborative requirement definition sessions ensures a smooth flow from definition to delivery. If a developer or a tester discovers an ambiguity in a requirement once they have started working on it, they'll need to resolve it. This interrupts their work, as well as the work of any colleague that they have asked to help. The elimination of interruptions and context switches leads to a more efficient, more predictable delivery process.

Another visible indicator is a reduction in the number of production issues. Although it is very hard to gather scientific evidence of this (because it is hard to find a control project), we have seen significantly fewer production issues in projects that have successfully adopted a BDD approach.

BDD helps preserve the quality and maintainability of the software, so a further indicator is that the implementation costs of new features are kept low. This is in contrast to many other projects where, as the code base grows, the cost of adding (or modifying) a feature increases exponentially. If allowed to deteriorate in this way, your project will finally reach the point where it is not possible to add new features anymore in a cost-efficient way and people will start talking about a rewrite.

Our goal with this book is to ease your way through the learning period, avoiding the mistakes that we made while we were learning.

One typical mistake is to see BDD as a tool box. BDD is primarily about collaboration and domain discovery; any BDD tool can only be useful in supporting this process. You have to start by investing in collaborative discussions and the creation of a shared vocabulary. Just going after automation (using Cucumber or SpecFlow) does not work.

It doesn't. Honest.

As we said, we don't believe in buzzwords, but if you intend to evaluate the BDD approach objectively, it is important to do it at full throttle during the evaluation period. You might feel uncomfortable or skeptical when you start doing BDD (as with any other new approach). That is absolutely fine, but don't let the evaluation be hampered by your fears. Once you have decided to evaluate how BDD could work for your team, give yourself enough time to get comfortable with the approach. Try, as far as possible, to follow our recommendations. You're at the beginning of a brave new world. Let's help you to explore that world and discover the benefits that are waiting.

• Explore why BDD exists, what challenges it addresses, and how it works.
• Establish structured conversations to finalize requirements.
• Discover techniques to form concrete examples that clearly list requirements.
• Gain insight into the tasks involved while following the BDD approach.
• Get good automated test coverage by tightly connecting tests and scenarios.
• Develop scenarios to get a functional breakdown of a story audience.