Is your team doing behavior-driven development but having issues realizing the full potential of this approach? In this episode Gaspar Nagy, creator of Specflow and co-author of the book Discovery: Explore Behavior Using Examples, discusses why BDD exists in the first place and shares proven techniques and tips for getting the most out of your BDD collaboration between the business and your delivery team members.
About Gáspár Nagy
Gáspár Nagy is the creator and the main contributor of SpecFlow, regular conference speaker, blogger (http://gasparnagy.com), editor of the BDD Addict monthly newsletter, and co-author of the book “BDD Books: Discovery – Explore behavior using Examples“. Gáspár is an independent coach, trainer, and test automation expert focusing on helping teams implementing BDD and SpecFlow. He has more than 15 years of experience in enterprise software development as he worked as an architect and agile developer coach.ial.
Quotes & Insights from this Test Talk
- BDD does not replace classic testing and testing skills. In fact, BDD itself does not define how testing should be performed. Instead, it provides a set of practical guidelines that facilitate the agile testing process.
- BDD is an agile approach that consists of three practices that have to be addressed in order. The first practice is discovery, a structured, collaborative activity that uses concrete examples to uncover the ambiguities and misunderstandings that traditionally derail software projects. The second practice is formulation, a creative process that turns the concrete examples produced during discovery into business-readable scenarios. The subsequent review of the scenarios delivers the confidence that the team really has understood what the business is asking for. The third, and final, practice is automation where the code is written that turns the scenarios into tests.
- Developing software is a process of learning. I’ve never met a team that, after they deliver some working software, say “if we were to do that again, we’d do it exactly the same way.” That’s because, in the course of developing the software, they discover things that they didn’t know at the beginning.
- You might have seen the term Specification by Example and assumed that this meant examples were sufficient to specify software. The intent, however, is to emphasize the use of examples to support a specification by making it harder for the rules to be misinterpreted.
- Without the business involved in BDD, unless the team is very business-focused and disciplined, the scenarios become technical, data-driven and dry. This means that the business get very little value from reading the scenarios and, consequently, won’t understand the implication of a failing scenario. This removes the possibility that
the scenarios will provide a constructive feedback loop between the business and delivery team – so the scenarios become an overhead. - BDD depends on collaboration!
Resources
Connect with Gáspár Nagy
- Twitter: @gasparnagy
- Blog: gasparnagy.com
- YouTube: Spec Solutions
- LinkedIn: gasparnagy
- Company: Specsolutions
May I Ask You For a Favor?
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page.
Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!
