Most software projects don't fail because developers can't code. They fail because the team builds the wrong thing. Requirements get lost in translation between business people, developers, and testers. Everyone reads the same document and walks away with a different understanding.
Behaviour-Driven Development, BDD, fixes this. Not with better documents — with better conversations.
As Aslak Hellesøy, the creator of Cucumber, put it: Cucumber is “the world's most misunderstood collaboration tool.” Most teams treat it as a testing framework and miss the point entirely. The tool is worthless without the conversations that come before it.
This course teaches you the full BDD cycle — Discovery, Formalisation, Automation, and Feedback — with hands-on exercises using real-world examples.
Day 1 — Conversations and concrete examples
You start where BDD starts: talking to each other. You will practice the Three Amigos format — product owner, developer, and tester in the same room — time-boxed to 25 minutes. You will use Example Mapping to break down stories into rules, concrete examples, and questions.
This is where the real value lives. Concrete examples surface the unknown unknowns — the risks you didn't know existed. A concrete example can be questioned. “Did you really mean that this should happen in that situation?” That question, asked before a single line of code is written, can save weeks of wasted work.
Day 2 — From examples to working software
Now the examples become executable. You connect Gherkin feature files to Java using Cucumber-JVM. You write step definitions, organise them by domain concept, and build a walking skeleton from specification to running application.
You will learn why your Cucumber scenarios should use the same language as your production code — and why scenarios written after the code is finished are just as bad as specifications written in a word processor.
What you bring home
Specifications that are living documentation, not shelf-ware. A team that speaks the same language. And the discipline to turn conversations into working, tested software — one concrete example at a time.