Many teams learn faster from examples than from rulebooks. Behavior driven development turns that habit into practice. Examples are mapped, refined, and written as readable scenarios. With tools like Cucumber, SpecFlow, and Reqnroll, these scenarios become executable specifications that guide vertical slices and reveal progress. The approach shortens feedback, reduces handovers, and avoids the small waterfall effect at the end of a sprint. It also builds a shared language across roles, which lowers risk and rework. Open source tools and communities play a key part here. The quiet lesson is simple. Start with examples, keep slices small, and let outcomes speak.
In this episode, I talk with Gáspár Nagy about behavior driven development. We look at why a simple example can beat a specification. You do not learn soccer from a rulebook. You learn by playing and watching plays. BDD uses the same trick to build understanding early. We discuss example mapping, writing readable scenarios, and turning them into executable specs with Cucumber, SpecFlow, and Reqnroll. Done well, this guides vertical slices, shows progress, and stops the mini waterfall at the end of a sprint.
"If you have a good understanding of the requirements, you can write better test cases, tests for that the developers might be able to make it immediately the right way and they don't need to do so much rework." - Gáspár Nagy
Gáspár Nagy, the creator of SpecFlow & Reqnroll, bringing over 20 years of experience as a coach, trainer and test automation expert nowadays through his company, called Spec Solutions. He is the co-author of the books "Discovery: Explore behaviour using examples" and "Formulation: Document examples with Given/When/Then" and also leads SpecSync, aiding teams in test traceability with Azure DevOps and Jira. He is active in the open-source community through leading the Reqnroll project. Gáspár shares his insights at conferences, emphasizing his commitment to helping teams implement Behavior-Driven Development (BDD).
In the latest episode of Software Testing Unleashed, host Richie welcomes Gaspar Notch—the creator of SpecFlow and ReconRole—for a lively, experience-rich discussion on Behavior Driven Development (BDD). While BDD is sometimes dismissed as just another testing technique, Gaspar makes it clear: BDD is much more than that. At its heart, BDD is about collaboration and shared understanding. It’s a development approach focused on these three pillars: better understanding of requirements, reliable verification, and effective documentation.
Gaspar explains that the most visible elements of BDD are its “scenarios”—textual descriptions of system behaviors written in plain language and commonly structured with “Given-When-Then” steps. Tools like Cucumber, SpecFlow, and RocknRoll help teams automate these scenarios, but the process starts much earlier: with shared examples and conversation.
Behavior Driven Development draws inspiration from the way people naturally learn: through examples. As Gaspar points out, no one learns soccer by studying the rulebook—they start by playing and watching others. With software, specifications alone rarely convey the full picture.
Instead, teams need to “work on that understanding together,” collaboratively creating examples that bring requirements to life. These concrete scenarios illuminate the often-missed details, uncovering ambiguities before they cause rework or misaligned solutions. Gaspar says, “If you have a good understanding of the requirements, you can write better test cases, the developers might get it right the first time, and the customer gets what they actually want.”
One common misconception is that writing BDD scenarios is the product owner’s responsibility alone. Gaspar quickly debunks this: true BDD means collaboratively creating scenarios with input from product owners, developers, and testers. This isn’t about optimizing for speed in the short term— it’s about ensuring shared understanding and setting the stage for fewer defects and smoother teamwork down the line.
Teams might use methods like example mapping or feature mapping, or simply facilitate their own discussions. The crucial ingredient is making scenario creation a group effort—the benefits show up in the clarity and completeness of both requirements and solutions.
It’s tempting for teams to force-fit every test case into the Given-When-Then format, but Gaspar warns this leads to convoluted, unreadable scenarios. BDD scenarios should be concise and focused on business behavior— not an exhaustive list of every possible edge case. Their main purpose is communication—both documenting and bringing requirements to life.
Gaspar recommends keeping BDD scenarios separate from traditional test cases, either by organizing them differently or labeling them clearly to avoid confusion. Readability is non-negotiable: “If you need a team of ten people to figure out what a scenario is trying to do, the value is lost.”
Once the team has agreed on scenarios, tools like Cucumber and its .NET counterparts (SpecFlow, and now RocknRoll) can turn them into automated tests. Each Given-When-Then step can be mapped to code that carries out the described action in the system. This process gives rise to executable specifications: documentation that stays in sync with both code and requirements.
Gaspar emphasizes that BDD is most effective when development is literally “driven” by these scenarios—implementing functionality step by step, example by example. This incremental approach (sometimes called vertical slicing) helps teams avoid “mini-waterfalls” within sprints, reduces stress at the end of iterations, and provides ongoing transparency about what’s done and what’s left.
Gaspar’s journey with BDD includes contributing to tooling such as SpecFlow and launching its successor, RocknRoll, for the .NET ecosystem. He highlights not just the importance of tooling for automation, but also how open-source collaboration mirrors the spirit of BDD: people coming together, across borders, to solve shared problems and advance the craft.
Behavior Driven Development isn’t about adding another testing layer—it’s about building a bridge between business and technology, creating space for clarity, collaboration, and confidence. As Gaspar and Richie demonstrate, the real magic of BDD is in the conversations it sparks and the shared understanding it creates.
If your team is looking for more meaningful collaboration and higher quality outcomes, BDD offers a path forward—one example at a time.