Cucumber BDD (Part 1): Starting with Feature Mapping

Disclaimer: This is an extension to my previous blog article: Behavior Driven Development (BDD) & Software Testing in Agile Environments. This tutorial explains on how to apply BDD concepts and identify stories (features) in a practical Agile environment. In my next tutorial, we are gonna build a sample Java project with Cucumber, TestNG, and Maven for the better understanding of concepts studied in the first two tutorials.
Also I have implemented the steps discussed in this blog post series here: You can clone this project, modify my code, and start writing your test suite on top of it.

Origin of BDD and Cucumber

In early 2000s, there was a small clique of people from the XP community who were exploring better ways to do TDD (Test Driven Development). Dan North named this BDD (Behavior Driven Development). He is now considered as the father of BDD.

In 2008, Cucumber was created and currently it is one of the most popular BDD tools available out there. Cucumber creators (Aslak Hellesøy and team) envisioned to provide a language, a process, and a tool that would provide a single source of truth of software behavior for the audience of both non-technical and technical project members. One needs to follow BDD principles to get the maximum out of Cucumber, because Cucumber is only an enabler for BDD.

The idea was to combine automated acceptance tests, functional requirements and software documentation into one format that would be understandable by non-technical people as well as testing tools.

In the book Specification by Example, Gojko Adzic nicely explains the BDD approach. If you want a handbook, BDD in Action by John Ferguson Smart is my best recommendation.

Behavior Driven Development (BDD)

In Agile environments, Behavior Driven Development (BDD) plays a vital role because it strongly encourages the use of Agile methodologies during the development and testing. BDD brings customers, end-users, BAs, QAs, and SEs of the software product into one table for effective sharing of knowledge on the system and its testing requirements.

BDD is a method carefully developed while keeping the principles of Agile Manifesto in mind.

Three Amigos

The people in charge of defining the requirements (business analysts / agile product owners) sit down with programmers and testers and discuss features (similar to agile stories) to be implemented.

  • The business person specifies behaviors they want to see in the system.
  • The developer asks questions based on their understanding of the system, while also writing down additional behaviors needed from a development perspective.
  • The testers decides on which system behaviors the acceptance tests will be written.

These three amigos (business persons, developers, testers) come up with examples of how the software should behave, and write them down as Cucumber Features and Scenarios. Thereafter the software development happens following the principles of ATDD (Acceptance Test Driven Development) and TDD (Test Driven Development).

Myths on Cucumber BDD

There are people who have misunderstood this concept of BDD and Cucumber features. Some of them use Cucumber as a testing tool and BDD as a testing method. Some write Cucumber features after the development of their software product in order to reflect its behavior. Although everyone has the freedom to use these tools as they wish, this crowd is missing the bigger purpose of this collaboration tool, creating a shared understanding among three amigos by discussing examples on expected software product.

Cucumber is first and foremost a collaboration tool that aims to bring a common understanding to software teams — across roles.

Therefore, it should be noted that BDD tools like Cucumber are made to drive the entire life cycle of software implementation in more collaborative manner.

Cucumber features should drive the implementation, not reflect it.
Cucumber is not a tool for testing software. It is a tool for testing people’s understanding of how software (yet to be written) should behave.
The biggest advantage of BDD approach for software development might be that they describe a set of functions that a user expects from a system in a very concrete and direct manner. The sum of these behaviors essentially document a contract with the user/client. If any of the tests fail, this contract is not upheld.

Let’s simulate BDD

Millennials love building stuff than reading docs. So let’s simulate the stages of BDD in a very high level manner and create a dummy project with Cucumber BDD to understand the workflow. Note that this is just for your understanding purposes :-)

Assume that our product is a web-based HRM software and we are gonna discuss the profile login and update features with specification by example method.

Writing Executable Specifications with Examples

This is the most important stage of BDD. Three amigos (business persons, developers, testers) get together and identify the expected behavior of our product by discussing examples. We can use feature mapping approach to effectively analyse and elaborate the product behavior.

Feature Mapping

Feature Mapping is a simple collaborative practice designed by John Ferguson Smart to help teams write great executable specifications. Feature Mapping draws on Jeff Patton’s Story Mapping, Matt Wynne’s Example Mapping, and other techniques.

In a nutshell, the process goes something like this:

  1. Define a feature or story, or pick one from the backlog.
  2. Understand what actors are involved in the story.
  3. Break the feature into tasks to identify the main flows.
  4. Identify examples that illustrate a principle or variant flow. Ask questions like: “But what if…”; “what else could lead to this outcome”; “what other outcomes might happen”; and use the answers to create new examples. Use rules to explain and give context to your examples.
  5. Rinse and repeat for other rules and examples.
  6. Create Executable Specifications: automate the main high-level flows with pending steps.
Feature Mapping Cycle

Assume that the discussions of our three amigos are happening now. They write the outcome of their discussions as high level features and scenarios in a business readable grammar. If you are familiar with agile, this process is very similar to the well-known agile story writing. The following are the features we discuss. Notice that they are very high-level and abstract.

Feature: Login Profile
As an employee of the company
I want to login my employee profile using my credentials
In order to collaborate with my colleagues
Feature: Update Profile
As an employee of the company
I want to be able to update my name, projects, email, and phone numbers on my profile
In order to share my contact information with my colleagues

In our case, notice that there is only one actor — the employee.

Now we are ready to break feature into tasks and scenarios.

Feature: Login Profile
Scenario: Successful login
Scenario: Failed login using wrong credentials
Feature: Update Profile
Scenario: Update name
Scenario: Add new projects

To execute scenarios, we need to establish the steps and rules involved in each scenario. For an example, let’s consider successful login scenario.

Before log into profile, employee must first visit the company home page. This is a precondition, i.e. background scenario which helps to successfully perform our expected scenario, successful login. So let’s identify its’ steps.

Background: User navigates to Company home page
Steps: 1) Go to company home page
2) See login option (this is a consequence of above step)
Scenario: Successful login
Steps: 1) Enter correct credentials
2) Login to account
3) See welcome message (this is a consequence of above step)

Now comes a tricky part, the realization of above features and scenarios. We need to get the inputs of developers and testers and convert above story-like scenarios to executable steps in Given/When/Then format of Gherkin language. Also, it should be noted that the business persons must agree with these steps.

Background: User navigates to Company home page
Given I am on the "Company home" page on URL ""
Then I should see "Log In as Employee" message
Scenario: Successful login
When I fill in "Username" with "Test"
And I fill in "Password" with "123"
And I click on the "Log In" button
Then I am on the "My profile" page on URL ""
And I should see "Welcome to your profile" message
And I should see the "Log out" button

NOTE: The above scenario is written to serve as a simple example and it is not the best approach to write scenarios. In production, always make sure that your scenarios are not tightly coupled with your tests. Your BDD scenarios should change only when the requirement changes, not when the the implementation changes (i.e. your BDD scenarios must drive the implementation, not the other way around).

Likewise, one can analyze all the features, describe behavior using examples, rules, consequences, and write them in the Gherkin format with the mutual agreement and understanding among business persons, developers, and testers. You can see this realizations in LoginProfile.feature and UpdateProfile.feature files in the below section. For now, let’s stop from here and see how the development work goes in my next tutorial: Cucumber BDD (Part 2): Creating a Sample Java Project with Cucumber, TestNG, and Maven :-)

Be sure to follow me on Twitter @ashen_wgt and send me your feedback, any questions you have, and also let me know your experiences and I’ll check it out/retweet! You can also check my other articles on Agile Vision.