Automation Testing Podcast Automation

197: Discovery Explore Behavior Using Examples with Gaspar Nagy

Gaspar Nagy

with Gaspar Nagy

creator and the main contributor · SpecFlow

April 8, 2018 Hosted by Joe Colantonio
197: Discovery Explore Behavior Using Examples with Gaspar Nagy

About this episode


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.

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

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.

SponsoredBySauceLabs

Test Talks is sponsored by the fantastic folks at Sauce Labs. Try it for free today!