A few years ago I was collaborating with a dear friend on a development project that had several comprehensive details, which made identifying functions and features challenging to say the least. That was when my friend asked, “do you know about Gherkin Language?”
When I answered in the negative, he explained the language to me and on the same day I started looking deeper into the language. Long story short, I discovered a whole new concept which could simplify the context of describing a feature or function development by creating an organized user story focusing on the project and its business requirement.
What is Gherkin Language?
Allow me to explain. We normally use gestures and the alphabet to express ourselves and communicate with each other.
However, more often than not, our message can get misunderstood by others. Similarly, in programming, writing software code or even during the software design process, a lot of code that is written goes to waste. This is caused by a number of reasons such as miscommunication.
It can also happen if the software\application is over-bulked with a lot of useless code, which affects the overall performance. It can also result from an over-stressed or over-burdened application because the scope of the work is confusing. In some cases, the developer may feel that the project could have been handled differently.
This compromises the productivity of the developer or development team and takes the project into an unpredictable timeline. The result? An emotionally and physically exhausted developer or team who are not as motivated as they were when the project first came in.
Even if everything is laid out strategically, and the feature or function is known and already defined (i.e. how it is supposed to work and what to expect from it), it isn’t enough. It needs to be written in a way that gives the developer a clear blueprint on what has to be done, how the features would work and what to expect from it. When the list of requirements is clear, the developer or development team can easily assemble the appropriate feature and functions to deliver what’s expected.
This is where Gherkin proves to be invaluable. The language works well with agile, since every sprint has to have the tasks that need to be completed, and each task must be well described so the developers understand what to do. This could be for code, design or the user experience.
Gherkin Language Terms
Gherkin works using the following terms. Each term has a specific description into it until the behavioral description is reached.
Defining Gherkin Behavior:
Feature: A feature in Gherkin is described by a Keyword, which the description is based on.
Background \ Description \ Story: Oftentimes, the description in Gherkin comes after the feature, giving description of the mentioned feature\keyword.
Scenario: After deciding on the keyword and adding background \ description or story, the next step would be providing a Gherkin Scenario. The Scenario in Gherkin is usually based on several steps (Given, When, And, Then, But) or (Given, When, Then, And, But)…
Here is an explanation:
GHERKIN EXAMPLE:
- Feature
Submit button in contact form page - Background \ Description \ Story
User \ Sender wants to send a message from the contact form page, the User\Sender finds a submit button when going to contact page. After filling out the information, the User\Sender gets a successful or fail notification.
SCENARIO:
- Given
User\Sender goes into contact page on my website, user will find a contact form with fields (Name*,Email*,Phone Number*, Subject*, Message*) and a submit button.
- When
User\Sender fills information in contact form fields. - And
User\Sender clicks submit button. - Then
User\Sender gets a notification message in a green box under the form (Your information has been sent, we will reach out shortly). - But
If User\Sender left a mandatory field unfilled. - And
Clicks on submit button. - Then
User\Sender gets a notification message in a red box (Please fill all information to send your message
THE PROS AND CONS OF GHERKIN LANGUAGE
The Pros
- Gherkin will help you structure your thoughts and put them into words.
- It is easy-to-read and easy to navigate for people who know it and even for those who don’t. Additionally, there are many editors that have Gherkin language so you can use it easily whether you are a veteran or a novice.
- It can be used per story or task, not just depending on the project type. Some stories are more complicated and have many scenarios – by following the Gherkin language structure you can structure and split your acceptance criteria in an easier way for you and the person who will read it.
- You can make the QA’s life easier, as they can use it directly in their test scenarios through the available tools that are available to them.
The Cons
- It can be very wordy sometimes, and you may find yourself repeating the same sentence over and over again in the same story.
- Some QA’s prefer to write the scenarios themselves instead of someone handing it over to them, since they feel they have to rewrite them anyway for their automated testing scenarios.
- No matter how detailed, or how many scenarios you think about, you will always end up missing a certain scenario or some acceptance criteria. So even Gherkin is not a replacement for continuous customer and product owner engagement – the development team will find themselves answering questions that might arise during the development phase.
- Although it’s easy to start writing scenarios in Gherkin syntax, it can be difficult to master. Many people (including myself) have mistaken scenario writing with user interactions on the interface, as scenarios should only reflect business outcomes regardless of the medium that the scenario is happening through. This is a point that a few people have noticed and it deserves an article by itself.
The bottom line is that Gherkin can help you set the feature with its description and expected scenarios in a way that allows your team more insight and help understanding the scope of work. The result? They can come up with more accurate timeline and will know what to expect as well as the results of a specific feature.
Though it takes a lot of work, is time consuming and requires research to figure out the expected scenarios, it will also be very beneficial for the QA and Testing team to understand how to test this specific feature for different scenarios.
The Gherkin language focuses on the project requirement particularly where expects user behavior to provide a better user experience through written Gherkin scenarios. While it can be really helpful, it really depends on your project and when you use it. The Gherkin language can slow down a project due to its elaborate scenarios. These focus on the end results to reach an enhanced user experience. So while it is a very helpful method to use, productivity can take a hit. In other words, your decision on when to use the language must be based on the scope of how short or big the project is and whether you have enough time to deliver.
Each scenario can take up significant time since you need to determine what to expect from it. Plus, developers would require more time to build a specific feature with its background and scenarios while the QA Testing will go through a detailed testing phase for each assigned scenario to ensure a high-quality end product.
However, since the Gherkin language requires a lot of communication between the development team members, it can go a long way in strengthening their work relationship. It can open up possibilities into multiple scenarios and discussions, which can end in a detailed and complete product. On the other hand, in some cases foregoing the language in favor of other suitable solutions (if you don’t need in-depth engagement, do not have enough time and if your developers will be writing their own testing scripts) may be a good idea.
Credits: I am extremely thankful for my friend (Imad) who helped compile the Pros and Cons in this article.
