On a simple search on Google about Gherkin you'll find a lot of info and varieties of cucumbers so maybe it is not just a coincidence that one of the automated frameworks that supports Gherkin language is called Cucumber :)
Cucumber is a software tool that supports behavior-driven development. Central to the Cucumber BDD approach is its ordinary language parser called Gherkin. It allows expected software behaviors to be specified in a logical language that customers can understand.
I am not going to lie, I am a big fan of Gherkin because along the way during my carrer I have tried different types of writing test scenarios which afterwards had to be automated also. While one of them was good for design but not really for execution and automation (descriptive steps in plain english - written as general as possible so that the tester executing it can remain impartial - with the associated acceptance criteria of the step, see picture 1). Another one was mostly too technical to be understood by anyone who would have a glance over it. It was appropriate for automation and execution but not really for understanding the purpose of the tests and for sure it was not easy to read (SQS type of tests, see picture 2).
Which brings me to describe my perspective and experience about using feature files written using Gherkin language (see picture 3). I found this technique the most satisfying as it allows both technical and non tehnical people to understand the behavior described in the test using a common language. At the same time the tests are easy to automate as the statements used in the feature file don't require further investment of time to be shapped and updated/re-written so that they can be automated. They are used as they are. So it kind of has the best out of the other two techniques I used for designing manual & automated tests.
Maybe the biggest advantage that I see when it comes to using Gherkin, is the fact that it helps you formulate requirements in an easy to read format, concrete examples of expected system behavior foster a shared understanding by being detailed enough for developers and testers while still making sense to business participants.
Based on clear requirements, the test scripts are afterwards written in the same not-subject to interpretation format. The feature file will become the most handy specification for the software. I have to admit that when I was put in the position of explaining someone how the software worked in a previous version I found it easier to go through an old feature file to remember how a certain feature has been implemeted rather than searching in the documentation archives. How did I do that? well that's the next nicer thing about using Gherkin, in colaboration with Git tools the feature files can be versioned and stored in a repository so the tester/developer is only a few clicks away from answering questions related to old behaviors/functionalities.
The main benefits of the team members, for the teams which are using Gherkin language are as follows:
The developers: get to spend more time on coding feature-logic rather than debugging and explaining code.
The testers: have the oportunity to use their testing skills throughout the entire lifecycle of the product rather than only starting at the moment they have the code ready.
The product owners: have a single source of truth for better collaboration with the other team members.
Picture 1:
Picture 2:
Picture 3:
References:
Gherkin Language - Use Your Language to Describe Test Cases (specflow.org)
Cucumber Testing Gherkin Language - javatpoint
