Stop Using Gherkin as Scripting Language
It is common and widespread across QA teams, but its utility is dubious, and far from the main objective.
--
Gherkin as scripting language
Before begin, I want to put things clear. Currently, I have seen two uses for Gherkin: BDD and QA-Scripting.
The latter is when we use Gherkin with intention to write a script, it shows what the user will do when interacting with the user interface. You can see a quick example here:
In this example, each step represent an action that the user does, or what he expects to see. You can follow it step by step and reproduce it in the application. You go to the login page. You should see the login form. It should have the username and password inputs, and the sign-in button. Then you click on the username input. And so on. It describes how you will test it.
The advantage is that it serves as a guide for making a test. And you can execute both by hand and by machine. Before implementing the test code, you can follow the test manually, or talk about whether the steps are right or not. So, you can verify its logic before investing time in coding it.
Why is it not BDD?
The purpose of BDD is describing, with each Scenario, one behavior of the application, through one example.
Reason 1: The Background is a Scenario itself. It first performs an action “Given I go to the Login Page”, and then it validates if the action is successful “Then I should see the Login Form”. The background should only have Given steps. Furthermore, the second check should not be necessary if we already had a scenario for that. Then-steps should be the closing of a scenario, not the beginning.
Reason 2: The language is wrong. The first Given is an action: “I go to the Login Page”. This sentence works as a When, not as a Given. Givens should express the situation, in this case, that I am at the…
