Who are you writing on Gherkin? Or gherkin in search of the target audience

:     Gherkin    ,  Gherkin          ,      

Not so long ago, among my friends, the question arose: “Why is Gherkin?”. Moreover, the question was not posed as a shovel, but in order to understand its applicability.

The discussion was started by a kuntashov in a G + note with the following content (here I give a dry residue, corrected quite a bit by me):

Gherkin was created so that usage scenarios can be edited as narrative (narration), i.e. “Almost human language” in a simple, concise form and accessible format. Those. The purpose of the format was to be primarily facing non-techies, but at the same time maintaining a more or less sufficient formality so that it could be automatically processed.
')
At the same time, business analysts or any other end users do not really want to read, let alone edit, scripts on Gherkin. Thus, the creation of feature files is shifted onto the shoulders of the developer, for whom Gherkin is an additional and possibly extra layer of abstraction. As we know, “abstractions flow” and the extra layer only increases the likelihood of “leakage”.

Can still use languages ​​that are more turned to programmers?

If there is a desire to jointly understand the usefulness of Gherkin and for whom it is intended, welcome under cat.
I emphasize that Gherkin = BDD, but BDD Gherkin.

Indeed, if you look at the tools that support the BDD concept, it immediately becomes clear that there are 2 dedicated camps:

• those who describe behavior on Gherkin and then do mapping with the development language. For example, Cucumber, SpecFlow, etc.
• those who describe the behavior immediately in the development language, but in a more natural form than the usual code. For example, Codeception, mocha.js, etc.

Gherkin, if anyone does not know, it is a language describing the desired behavior of the system. In view of its proximity to natural language, there is an attempt to kill two birds with one stone - to automate testing and create “live” project documentation. Those who want to learn more - click here (eng) or here (rus) .

Gherkin and business / analyst representatives

Initially, Gherkin was positioned as a tool for analysts and business representatives. I will explain a little bit that by business representatives I mean business experts, product owners, analysts, subject matter experts, etc.

Why is he not going?

Despite the maximum proximity of Gherkin to the human language, it is still a programming language. Those. we ask the business to program a little ... How do most people do when they are asked to do something that they don’t really understand and, by and large, shouldn’t understand? Procrastinated or rebelled.

Gherkin and developers

So, we decided. Representatives of the business, as a rule, cannot and do not want to describe formal scenarios. Well, throw it on the shoulders of developers.

Why does not go here?

The fact is that the overwhelming majority of developers have a brain that is designed so that they have cognitive resistance against writing tests to code. I remember my feelings when I started trying TDD. The usual way of thinking completely breaks down, there was a feeling that my left and right halves of the brain change places ... HOW? HOW I can test what is not written yet!?!?!? Only after the reorganization of thinking, such an approach begins to be felt as natural and begins to bring benefits.

Moreover, not all developers are able to design test scripts. Designing a test script is a special process that is also not natural for developers. Developers - creators who are not up to the issues of validation and verification.

It is also worth paying attention to the absolutely logical remark that Gherkin is an additional layer of abstraction for developers. Why do I need to write something on Gherkin, if I can do everything in the application language right away? Of course, Gherkin for developers looks like a completely unnecessary link.

Gherkin and someone else?

Well, business representatives cannot / do not want, developers cannot / do not want. So for whom was this instrument invented? Who can he use?

Maybe the problem lies in the wrong positioning and the wrong choice of the target audience?

And what if we assume that the target audience of Gherkin is testers? And not just testers, but flexible testers (agile testers). The skill of creating test scripts in their blood. A mindset allows you to isolate the most important and necessary scenarios for testing and it is easy to describe them. Still, these are people who later have to test the future system. So, they are interested in the system that gets to them - has clearly defined specifications and behavior scenarios.

Yes, it reverses familiar logic. Yes, the tester starts its work before something is developed. But after all, in fact, TDD and BDD are just about that ...

And there will be no problems with the fact that:

1. testers should “spit at the ceiling” half of the iteration, and then quickly drive it all away quickly;
2. testers work on their own, “displaced,” say, a week, sprints.

At the end of the iteration, the most interesting and difficult part will remain - research testing, which rarely has enough time for normal development.

Then the question arises: “Do we change business analytics for a flexible tester of an armed Gherkin or something?”.
No, we do not change. We complement the requirements formulation team with a tester. For clarification, I want to refer to the testing matrix:

In my opinion, Gherkin, an explicit representative of business-oriented tests that support the development. In other words, this is the second quadrant (Q2). Tests of this quadrant are primarily aimed at gathering requirements. What would the requirements collection process look like when we have a tester with Gherkin?

In modern development, new features begin their lives in the form of user stories written by a business team. Writing stories does not imply the elaboration of details. Stories are only intended to serve as a starting point for dialogue between business and development teams. Here, testers play an important role in helping to select examples and context for each user story. It is at this moment that Gherkin scripts are born and a common information space appears for all participants in the process. Understanding the problems of business, technical specialists will be able to offer more practical alternatives in their implementation. The use cases received as a result of the discussion are approved by the business. In the future, these scripts are a guide for developers in the process of writing code and help to know when the code begins to meet the requirements of the business.

Summarize

For a business team, Gherkin can only be useful if there is a specialist in the team who understands technology and the skills of a programmer.

Developers Gherkin probably does not help, but forces them to perform some additional, possibly unnecessary actions. For a developer, test automation is easier to perform in the first quadrant (Q1) of the test matrix, at the unit test level, they can just look like in the BDD style (codeception, mocha.js, etc.).

Testers, in my opinion, the optimal target audience for Gherkin. Not all testers program, but they can master Gherkin quite easily. At an early stage, some of the testing work is done and time is left for other types of testing, for example, research.

I also want to note that, in my opinion, tests from quadrants 1 and 2 (Q1 and Q2) should not be opposed in any way, they are an excellent complement to each other!
Tests of the first quadrant give such a wonderful artifact as a high-quality design of the program code.
Tests of the second quadrant give confidence that the business will get what it expects, and not what happened.

What do you think about this?