Gherkin language Importance

What is Gherkin – behavior-driven development [BDD] Language?

Before headfirst in to Gherkin, it is essential to know the significance and need of a common language across dissimilar domains of project. By different domains BDD By dissimilar domains I mean Clients, Developers, Testers, Business analysts and the Managerial team. Let’s jump with conversation about usual difficulties of a development project first and then we will move to a resolution, while doing so we will come across the need for a collective language.

Undertake you are a part of a technical team (Developer and Tester) and you have an assignment of work together with the business team (Business owners and Business analysts). You have to arise with the requirements of your project, these requirements will be what your development team will be instigating and test team will be testing. Also, that you have to make a small exploration feature on your E-Commerce platform. This feature will permit users to search for a product on your website.

As we all might have met in our experience that requirement given by business team are very unpolished and elementary. For example, in this scenario we may get following requirements:

 3.    Functional Requirements

3.1    Search Functionality

3.1.1     Members should be able to search for a product

3.1.2    Only the products associated to search string should be displayed.

 Questions raised from the above requirements

As we can see these requirements are decent and useful but are not exact. They define a extensive performance of the system but do not specify real behaviour of the system. Let me show it by separating the first requirement, primary requirement states that member should be able to search for a product but it flops to specify following

- What is the extreme searchable length of search string?

- What should be the search results if members searches for an unacceptable product?

- What are the effective characters that can be used to search?

*and likewise a few more exhaustive behaviour of the application.

Usually in a project we end up examining above questions with the business team and we get answers, most of the answers reach the project documentation but the luckless ones are lost in emails and telephonic talks. Also these answers are open to clarification, for example:

Question to Business Owner: What should be the search results if members searches for an invalid product?

Reply from Business Owner: Invalid product searches should show following text on the search page: No product found

Answers of the Questions result in to more Doubts and Interpretation

We get the answers of the questions asked from the Business team but it opens for interpretation or doubts in following ways:

- Definition of invalid product is confusing and different team members will interpret it in different ways. One may study that an invalid product is one which is not present in the list and other team member might consider an invalid product to be one which is a spelling fault.

- The answer by the business team declares that “No product found” text should be displayed on the page. Does it says that a new exploration option should be present for the user? Or may be related/similar search choices should be displayed for the user?

These are exact points where fault is introduced in the system. Also, if we analyse the second doubt we would see that user Business team would love to have a new search option and related/alike searches option accessible to the user. However, they were not able to consider of this scenario when the question was asked. As a result what happened in the above example is

1. Business team and the technical teams are interactive at two different levels, business team being unclear and technical team trying to be specific.
2. Ambiguity being presented in the system, here by the explanation of “invalid product”.
3. Not enough vision being given to the Business team, so that they could have turn up with fresh scenarios.
4. Some details of project being lost in emails and telephonic talks.

How to Improve the Requirement?

Now let’s improve the primary requirement given by the business team and try to make it more accurate:

“When a member searches, without spelling mistake, for a product name existing in the inventory. All the products with similar name should be displayed“

“When a user searches, without spelling mistake, for a product name existing in the inventory. Search results should be exhibited with exact matches first and then related matches“

Here we can see that how strong the requirements have become and with these rich requirements we are able to think more around the system. For eg. In the case of second requirement, after interpretation it we may think of extra scenarios like:

• What should chance when there no exact and similar matches?
• Should the user be assumed an error message?
• Or the user is given a message stating when the product is normal to arrive in inventory.

What have we realized here?

We have enforced the client to think in terms of specifics. With this improved thinking Business teams are approaching with more polished requirements. This in turn with decreases the ambiguity in the project and will make developers and testers life informal by reducing the number of improper implementations. Also, you can see that apiece requirement now documents one careful behaviour of the application. This means that it can be measured as a requirement document in itself.

What’s the conclusion?

Well, with the above example or workout we can accomplish the followings:

1. Different teams in the project must a common language to express requirements. This language should be simple enough to be understood by Business team members and should be explicit enough to eliminate most of the ambiguities for developers and testers.
2. This language should open up the thinking of team members to come up with extra scenarios. As you express further details you try to visualize the system more and hence you end up making additional user scenarios.
3. This language should be decent enough to be used as project documentation.

To answer these problems Gherkin was created. Gherkin is a simple, lightweight and organised language which uses regular spoken language to define the requirements and scenarios. By regular spoken language we mean English, French and around 30 additional languages.

Example of Gherkin

As Gherkin is a structured language it trails some syntax let us first see a simple scenario described in gherkin.

Feature: Search feature for members
This feature is very important because it will allow users to filter products

Scenario: When a member searches, without spelling mistake, for a product name present in inventory. All the products with similar name should be exhibited

Given User is on the main page of www.onlineshoping.com
When User searches for mobiles
Then search page should be updated with the lists of mobiles

Gherkin contains a set of keywords which define dissimilar evidence of the scenario. As we can see above the coloured parts are the keywords. We will discuss around the gherkin test structure in details later but the key points to note are:

• - The test is written in plain English which is common to all the domains of your project team.
• - This test is structured that brands it capable of being read in an automated way. There by making automation tests at the same time while describing the scenarios
•  Source: QA tools