How to Write Effective Scenario Using Gherkin Syntaxes

About Gherkin

Gherkin is a plain-text, business-readable, and domain-specific language that helps you describe business behavior without going into detail about implementation. Gherkin serves two purposes.

1. Documenting user scenarios
2. Writing automated tests.

It is easy to write application behavior so anyone can understand your business need and at the same time Automation Engineer can use these statements to automate the behavior of the system.

The following are rules for Gherkin:

1. The Gherkin feature file should have a description of the single feature.
2. The source file should have the .feature extension

Gherkin Keywords:

1. Feature
2. Scenario
3. Scenario Outline
4. Background
5. Given, When, Then, And, But (Steps)
6. Examples

1. Feature:

The feature starts with the keyword Feature and after that, it has a description that provides the context. It is usually written this way:

As a [role] I want [feature] so that [benefit]

A feature contains one or many scenarios that describe its behaviors. Every feature should be able to be executed alone and should not have any dependency on another feature.

2. Scenario:

Each feature file can have one or multiple scenarios and each scenario starts with the keyword ‘Scenario’ followed by a scenario description. The data table can be used in the Scenario to provide more detail about test data in the following way for any steps:

Note: All lowercase and “_” separations are recommended for the data table header.

3. Scenario Outline:

Scenario Outline can be used when the same scenario needs to run multiple times with different sets of test data. Scenario Outline allows us to more concisely express these examples through the use of a template with placeholders. Replace Scenario with 'Scenario Outline'

4. Background:

Background allows adding some context to all scenarios in a single feature. A background is like an untitled scenario, containing several steps. Background runs before each of your scenarios so there can be only one background per feature file.

Best Practices to use Scenario, Scenario Outline, Background

Combine common scenarios in Scenario Outline to ease of readability and maintainability. Reword your steps more generically so they can be reused to run multiple scenarios.

Combine common steps for each scenario in the given feature file in Background. You need to be very cautious about using Background as any given steps in Background will run before every scenario and will add time to execute the Automation Test Suite.

5. Steps (Given, When, Then, But OR And)

• Given - Precondition or Setup (Must be first and always required)
• When - Action (Optional - Not required when there is no action)
• Then - Assertion (Required)
• And, But - Wild cards (They match the keyword above them)
• But - Generally negative assertion (rarely used)

6. Examples:

• Single Assertion
• Multiple Assertion

Best Practices for Steps

• Be as descriptive as possible with each step but try to be less than 100 characters (recommended between 50 to 80 characters).
• There should be no identical steps across scenarios and feature files unless they have the same purpose and impact.
• Make your steps information independent. In the below example, the second step is correct because it provides enough detail and is not dependent on previous steps to provide detail.
• Connect your scenario to your requirements. Following are two ways to connect your scenarios to requirements

Example 1:

Scenario: Description of the scenario followed by the Jira ticket number: ABC-01, ABC-02

Example 2:

# ABC-01, ABC-02

Scenario: Description of the scenario followed by the requirement as a comment

• Make your steps modular using the following:

1. Be consistent with your language (For Example: When the user clicks on the “Report” link. And the user clicks on the “Configuration” link) which helps to make these steps reusable in automation.
2. Use Parameters to make them clear - in the above examples, the words Report and Configuration are parameters and can be changed by any other link.

5 Rules to Make Your Steps Modular

1.?If they do the same thing make it obvious (to standardized language)

When I click on the “Report” link on the “abc” page

And I click on the “Copy” button on the “xyz” page

“The same action can be written in the same way”

This is useful for automation to just reuse the same step for both actions

2. Keep case consistent: lowercase recommended

Above both will not execute the same step as “Click” and “click” are 2 different actions for an automation tool.

3. Keep tables consistent - lowercase and underscore separated

4. Include all needed information as if the feature, scenario, or step were alone

5. Don’t use Microsoft Word to create your steps - Microsoft uses smart quotes which will break automation

Comments:

If your step or scenario contains logic that might be complicated for the development then add a comment in the following format

#! Insert dev comment to be removed by a person who will automate that test once implemented

# Insert general comment which will stay.

Keep general comments at the top of your scenario or feature. Place Dev comments where needed.