BDD stands for Behavior Driven Development. At the heart of BDD are Stories connected by concrete Rules and Examples. The stories can then be connected to tests. These tests are written in a ubiquitous language that all stakeholders understand, and are also used for development. Through this we can create “living documentation” that resides alongside the code, greatly increasing the chances that documentation will stay up to date. 

Seb Rose describes it as a way to “ out what your customer or business wants from the software before you start working on it … collaborate with those people… [and then] record that in a way that is meaningful to anybody reviewing it … if it’s appropriate to our teams and our projects, we automate our tests to drive the behaviour.” (

BDD enables teams to practice “Outside-In Development” where the tests are written prior to coding.  The tests fail until code meets the requirements of the test. In this way, it mimics Test Driven Development (write test > write code with goal of passing test in mind > run test to verify code > repeat until complete). The underlying philosophy of BDD and the strategies involved make it solid and powerful; its basic principles ring true for software development projects across the board. 



BDD Kickstart


A while back, I attended a 2-day BDD Kickstart training and learned a lot about BDD and Cucumber. The lessons learned come to mind daily, and have enhanced my skills as a Business Analyst and software tester. This article combines reflections on BDD Kickstart with insights from a BA and testing perspective. 

The key takeaway from BDD Kickstart was a better understanding of how collaborative software planning, development and testing must be considered as integral parts of a whole. Again and again, we return to the word “collaboration” when discussing the process of developing successful software. Collaboration is critical when approaching software development and testing using BDD methods and tools.



BDD Kickstart, Day 1: Example Mapping and Gherkin


Day 1 of BDD Kickstart focused on Behavior Driven Development, Example Mapping and Gherkin. Students discussed their experiences with software development and testing, and were then put into small groups. Each group tackled questions about how to get a team to communicate in order to define the examples and rules for stories about software behavior (Example Mapping). 

Example Mapping: What is it?
Example Mapping is a collaborative effort to document how the software should behave by defining succinct Stories, Examples and Rules during the Discovery phase of the software development process. The goal is to paint a complete picture of the business requirements in a way that everyone understands. 

This is often done during group “Specification Workshops” or Example Mapping sessions involving a group referred to as the 3 Amigos. Often the 3 Amigos will include the Product / Business Owner, a Business Analyst and a developer; the group may also include a tester, or a SME for software that interacts directly with what is being developed. The 3 Amigos “standard” is a general guideline to emphasize the importance of having multiple actors involved in the Example Mapping process.

Example Mapping forces us to think about requirements from the Outside-In. We start with the end in mind and involve everyone in creating the Stories, Rules and Examples. Thinking hard and asking questions during this process helps uncover unknowns, or specifics that may be overlooked if only one stakeholder were involved in defining the requirements.

Example Mapping uses colored index cards to document details during the sessions. Card colors and their use are as follows:

  • Yellow (Story Card)

    • A single User Story that is typically the starting point for discussion.

  • Blue (Rule Card)

    • Rules are the acceptance criteria, and should be placed beneath the yellow story card.

  • Green (Example Card)

    • Each rule may need one or more examples to help illustrate it, so place these cards beneath the blue rule cards.

  • Red (Question Card)

    • Through discussion, questions often arise that none of the participants can answer. Document these on a red card and proceed with the session.

To learn more, see

Example Mapping should make it EASY to create review-ready acceptance criteria. Any questions that arise during these sessions should return the story to the beginning of the example mapping process. The group can then re-evaluate it collaboratively, and adjust the Rules and Examples as needed to suit the newly defined or understood criteria.

Example Mapping is where the team defines and describes the software’s intended behavior using rules and examples. These can then be connected to automation in order to create living documentation. This “living documentation” is where Gherkin and Cucumber come into the picture...

About Cucumber and Gherkin
Gherkin becomes part of the software development and production process when we take the stories, as expressed in rules and examples, and connect them to / implement them as tests (Gherkin Scenarios). Gherkin Scenarios must be written in a common language that represents the organization’s way of thinking, using the understood and agreed upon Domain Specific Language. In the code, this language is used as a representation of the system.  

Cucumber understands the language Gherkin. It is a Business Readable, Domain Specific Language that lets you describe software's behaviour without detailing how that behaviour is implemented.
Gherkin serves two purposes — documentation and automated tests. The third is a bonus feature — when it yells in red it's talking to you, telling you what code you should write. (

Cucumber is a tool created to help avoid misunderstandings and ambiguity around business rules. 
As Seb Rose puts it: Cucumber is not part of BDD. Cucumber is something that has been created to help people automate in a specific way. (
At its core is the collaboration around building it into the software development process.
It brings together automated acceptance tests, functional requirements and software documentation into one format that can be understood by developers, non-technical people and testing tools. In other words, Gherkin is written so that both computers and humans can understand and use it. 

The basic structure includes:

  • Given

    • This is the context. It provides a way to “ready” the system (set it up) for a specific scenario.

    • If there are multiple Givens, or specific elements that must be in place to set the system up for the scenario, And steps are used.

  • When

    • This is the action. It describes a specific action for the particular scenario.

  • Then

    • This is the outcome. It describes what should happen as a result of Given and When.If there are multiple outcomes, or Then-type results that occur following the When action step, And steps are used. 

Here’s a simple example of a Gherkin Scenario:
Given an anonymous user session
When I request a new user account
And I enter a valid username and password
Then my new user account should be created 

It’s important to note that we must keep these Scenarios simple. Developer-level details are not part of the scenarios, but are maintained in the step definitions. Also, scenarios should begin from a stateless point that assumes the system starts in a default or “blank” state. 

It is important to keep the Scenario names up to date, to keep them valid. Cucumber does not care what the scenario name is or if it has any bearing on reality of the system. If your Scenario name reflects deprecated functionality, it loses its value as living documentation.  

The Scenarios are combined into Feature Files. An entire Feature File can be run, or a single scenario can be run from within a feature file. 



BDD Kickstart Day 2: Pair Programming _ Scenario Development and Cucumber

The second day was spent doing pair programming, partnering an experienced programmer with a non-programmer. Pairs developed tests for a fictitious app in Java, using Gherkin syntax and Cucumber. 

Obviously, I was the non-programmer of the pair. My programmer partner hadn’t done much with Java in the recent past, so it was a great learning experience for us both. This exercise really opened my eyes to the problem-solving process involved in coding. It was great to witness the trial and error as a line of code was introduced and run, and then tweaked and re-run… Listening to the other pairs explain how their code was written showed me that there are often many “right” ways to tackle software problems or meet requirements.




Collaboration is key to successful BDD. One could argue that communication is the whole point: Getting people to truly understand one another in order to define the software requirements concisely _ to literally be on the same page. After all, if the team cannot collaborate and agree on what the software should do when and why, and how to get from A to B in our user journeys, the efforts of the project team are likely to be wasted.

Whether or not your team incorporates automation into their BDD practice, the technique helps us achieve two critically important things in our successful software implementations:
1. Build the right thing
2. Build it the right way

Try some BDD-style collaboration on your next software project, and reap the benefits of this great development tool!