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
- Business team and the technical teams are interactive at two different levels, business team being unclear and technical team trying to be specific.
- Ambiguity being presented in the system, here by the explanation of “invalid product”.
- Not enough vision being given to the Business team, so that they could have turn up with fresh scenarios.
- 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:
- 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.
- 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.
- 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
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
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
