Blog

Gherkin: speaking the same language with automation engineers

Read about Gherkin - plain-text language enabling testing engineers to create automated tests on their own.
17 October 2016
Test automation
The article by a1qa
a1qa

Sergey Senyuk, Manager of Test Automation Department at a1qa, speaks about Gherkin, a language designed for non-programmers that can help to describe system behavior and create automated tests without deep knowledge of programming.

What languages do automation engineers speak?

To build an automation framework and create a scope of automated tests, the developers may use a variety of languages: C#, JavaScript, Ruby, and many more. Each of the languages has its own syntax.

The choice of the language may be conditioned by client’s preferences, automation team expertise or by a set of specific libraries for a certain tech stack. And while the programming skills are a matter-of-course for engineers who are engaged in developing automation solution, the end-users of the solution aren’t necessarily experts in coding.

However, they’ll have to launch tests, analyze the reports and support them, i.e. bring up-to-date after the UI or application business logic has been changed.  The automation solution shall be beneficial for the end-client, easy-to-use and convenient.

Users of automation solution – who are they?

After the automation solution is developed and handed over to the client, it’ll be used by the following specialists:

  • Automation engineers themselves (obviously, there shall be no problems in understanding the language);
  • Clients’ developers (generally the solution will be created using the same tech stack as the in-house developers do, therefore there also shall be no troubles in script understanding);
  • But most commonly the solution will be handled by the client’s QA department. And this is the point where troubles I want to talk about occur.

The essence of the problem was perfectly defined by one of our potential clients after he saw our automation framework and learnt our approach.

He imparted his apprehensions for the ability of his QA team, who had no experience in writing code, to support the scripts, say nothing about writing their own scripts.

When testing engineers without programming skills are the end-users of the solution, our team suggests building a solution by implementing the BDD (Behavior-driven development) approach.

Why is BDD approach so remarkable?

Primarily, BDD is the methodology of software development and it suggests that the expected behavior of the system should be described in terms of plain-text scenarios. After that the described functionality is developed and, when delivered, the predefined testing scenarios should be successfully executed.

A scenario is the description of the system functional behavior written in human language by a definite pattern. As the automation engineers and testing engineers should be able to work together with the solution, scenarios are written in a ubiquitous language.

A ubiquitous language is a living language that can be used to facilitate communication between programmers and non-programmers and, at the same time, can be perceived and interpreted by the automation scripts. As a result, there is no need to improve or modify the documentation for the development or QA team usage. All scenarios are described in the same way and can equally be used by all teams involved.

Describing test scenarios with Gherkin

Executable specifications can be created in Gherkin – plain-text language that can be learnt by non-programmers. Gherkin fulfills two goals simultaneously: it serves as project documentation and automates testing process.

The system behavior is described with the keywords Given/When/Then. Every new line in Gherkin starts with one of these words which is followed by a description.

According to BDD approach, a desired behavior should be specified in terms of user story in the following way:

Title. It should be clear and explicit.

Narrative. A brief, introductory section specifying:

  • who is the stakeholder of the story or who will derive benefits from it
  • what effect the stakeholder wants the story to have
  • what business value the stakeholder will derive from this effect

BDD does not have any formal requirements for exactly how user stories must be written down, but it insists that each team using BDD should come up with a simple, standardized format for writing down user stories which includes the elements listed above.

A brief example of this might look like this:

As a [X]
I want [Y]
So that [Z]

where Y – is a feature, Z – is a benefit of using the feature and X – is a user or group of users who will benefit from the feature.

However, behavior specification in Gherkin is completely another story. Every line here is a definite step which corresponds to one of the code methods.

Every scenario shall start with a precondition. It may consist of one point or of many of them. The precondition starts with the keyword [Given].

After that the actions that will take place in the scenario are described starting with the word [When].

Finally goes the outcome description with the starting word [Then].

If there is more than one step in any of the blocks, each of them should be written down in a separate line with a keyword And.

Example of specification in BDD

Feature: Log in to the app

As a user

I want to log in

So that I make a payment

In Gherkin this scenario will be described as follows:

Given User is on Login Page

When User enters following credentials and submit

|Name         |Value         |

|Login          |test_user  |

|Password   |pass           |

Then ‘Welcome to our site’ message should be displayed

Most of the BDD frameworks are multilingual Cucumber, for example, supports 60+ languages with this number constantly growing.

Key reasons to learn Gherkin

  1. System behavior is specified in a plain way that is clear for all project participants.
  2. Files that contain specifications are executable automated tests at the same time.
  3. Test documentation and automation scripts indivisible and are saved in one project.
  4. Natural language constructions allow to build variable scenarios and to create new automated tests without reviewing the code.

With that all said, we recommend all our QA colleagues to learn Gherkin as this is the easiest way to start talking with automation engineers the same language.

In the next article we’ll talk on how to build effective communication between testing and automation engineers on BDD projects.

More Posts

Enhancing Agile and DevOps processes
28 February 2024,
by a1qa
4 min read
4 actionable tips to enhance Agile and DevOps processes 
Streamlining Agile and DevOps workflows? Learn practical recommendations on how to achieve this.
Agile
General
Test automation
Navigating the future: QA trends that will define 2024. Part 1
15 January 2024,
by a1qa
4 min read
Navigating the future: QA trends that will define 2024. Part 1
Discover topical software testing trends that will shape 2024 and empower companies to smoothly implement advanced technologies.
Agile
QA trends
Quality assurance
Test automation
The year in valuable conversations: recapping 2023 a1qa’s roundtables for IT executives 
8 December 2023,
by a1qa
3 min read
The year in valuable conversations: recapping 2023 a1qa’s roundtables for IT executives 
From dissecting novel industry trends to navigating effective ways of enhancing software quality — let’s recall all a1qa’s roundtables. Join us!
Big data testing
Cybersecurity testing
Functional testing
General
Interviews
Performance testing
QA trends
Quality assurance
Test automation
Usability testing
Web app testing
na-st-awards-23
16 November 2023,
by a1qa
3 min read
a1qa shines as the finalist in three categories of the North American Software Testing Awards
a1qa is a triple finalist at the North American Software Testing Awards.
General
Quality assurance
Test automation
3 November 2023,
by a1qa
4 min read
From idea to buying: 7 testing types to make your mobile eCommerce solutions flawless
Read the article to discover 7 QA activities helping boost mobile eCommerce solutions quality and provide end users with exceptional buying experiences.
Functional testing
General
Quality assurance
Test automation
Usability testing
On the way to Web 3.0: key software testing aspects for seamless digital experiences. Part 2
12 October 2023,
by a1qa
4 min read
On the way to Web 3.0: key software testing aspects for seamless digital experiences. Part 2
Let’s analyze essential software testing checks to improve the quality of the business-critical Web 3.0 functionality.
Cybersecurity testing
Functional testing
Performance testing
Quality assurance
Test automation
Usability testing
On the way to Web 3.0: key software testing aspects for seamless digital experiences. Part 1
11 October 2023,
by a1qa
4 min read
On the way to Web 3.0: key software testing aspects for seamless digital experiences. Part 1 
In part 1 of this article, learn about the transformation to a new Internet era, Web 3.0, and its benefits for increasing operational efficiency.
General
QA trends
Quality assurance
Software lifecycle QA
Test automation
goodfirms-lists
26 September 2023,
by a1qa
2 min read
a1qa’s recognition by GoodFirms: A testament to our expertise
Delve into a1qa's recent acknowledgment by GoodFirms and explore the significance of this accolade in the sphere of software testing.
General
Performance testing
Test automation
ai-ml-test-automation-mini
21 September 2023,
by a1qa
5 min read
6 activities to supercharge test automation with AI and ML
How to maximize the benefits of test automation? Learn how to do it via applying AI and ML.
Test automation

Get in touch

Please fill in the required field.
Email address seems invalid.
Please fill in the required field.
We use cookies on our website to improve its functionality and to enhance your user experience. We also use cookies for analytics. If you continue to browse this website, we will assume you agree that we can place cookies on your device. For more details, please read our Privacy and Cookies Policy.