My approach for writing E2E scenarios using Gherkin!

I have been talking in various forums and wrote articles on how to write effective Gherkin scenarios for your business requirements. You can find them here.

One question that my audience ask very often is –

How to write Gherkin scenario for end to end scenario by following 3 golden rules? I have series of steps and pages that I need to navigate and complete my journey. In that case, how am I suppose to use only maximum 5 lines of GWT’s (Given When and Then)?

This is absolutely a valid question. As a matter of fact, I write end to end scenarios in Gherkin too. So, this is how I mitigate the problem of writing a lengthy scenarios in Gherkin format or rather a scenario in a feature file.

Example Scenario:

Let’s consider an example scenario from this website – http://automationpractice.com/index.php

Below is the scenario for which we will write the Gherkin formatted scenario.

• Step 1 – Login into the application
• Step 2 – Enter “shirt” in the search box and hit enter
• Step 3 – Click on More button for
• Step 4 – Select size “M”
• Step 5 – Click “Add to cart”
• Step 6 – Validate whether “Product successfully added to your shopping cart” text is visible
• Step 7 – Click on “Proceed to checkout>” button
• Step 8 – Again click on the “Proceed to checkout>” button
• Step 9 – Again click on the “Proceed to checkout>” button
• Step 10 – Agree to terms and conditions
• Step 11 – Click on “Proceed to checkout>” button
• Step 12 – Check the total amount to be “$18.51”
• Step 13 – Click “Pay by bank wire”
• Step 14 – Click “Confirm my order” button
• Step 15 – Validate whether “Your order on My Store is complete.” text is visible
• Step 16 – Logout of the application

Observation: The above scenario has 10 different pages to be navigated to place an order.

NOT a best practice:

Let’s now see how we can write it in Gherkin format –

Many of us misunderstand the concept of reusability in Gherkin. What we see in the above scenario is just a replica of your “TEST STEPS”, there is no business cause involved at all.

The point is, we think Gherkin way of writing tests is replicating the way that we do our traditional test steps. Gone those days! In a BDD project, when we write our acceptance criteria we should craft the requirements and not bombard with steps like above.

Now, let’s see how to write the above scenario in a business level acceptance criteria / requirements.

Hold on! You might be thinking about asking the questions –

• Where are the other steps?
• Where is the reusability here?
• What if I need to debug and see where my test execution fails?

Well, here is what I understood with all these times writing Gherkin.

• Try to simplify your scenario
• Keep it high level
• Use Comments to add requisites and scenario description
• Make it more business oriented and less test oriented
• Validate the business outcome and not the test outcome

Note: I totally agree that there might be situations where you need to feed more data in every page, in that case, try using in-step arguments or better use an excel sheet that can be manipulated in your step definitions or utility classes.

Here are some tips I follow –

• Many of us as testers, think about reusable Gherkin steps. I didn’t think like that.
• Rather, I started thinking about the reusability from step definitions and page objects layer.
• I control the scenario flow from the step definitions and not from Gherkin / feature file as it adds extra work for maintenance of english statements
• Never used locators from my Gherkin

A Million Dollar Question!

I write my scenarios in chunk and when it comes to E2E, I am forced to rewrite the scenarios in Gherkin and it takes a lengthy ones.

Agreed! that’s where the 4 layered architecture comes in to picture. Like I said earlier, I start writing all the reusable steps from second and third layers – step definitions and page objects.

For example, while I automate the scenarios for my sprint stories (acceptance criteria), where the module is small, I think about writing the reusable step definitions and page objects, so that I can tailor the Gherkin / feature files later point of time and call the appropriate functions technically.

From the below diagram, the reusable layers where we need to focus more is in grey colour.

Why I chose this approach?

We all know that the Gherkin are for all types of stakeholders like BA, PO, Architects, Designers, Devs and Testers. So, we need to keep it more simple and understandable by everyone. That’s the reason, I am keeping my Gherkin simple and neat.

When the scenarios are lengthy, at least with my experience, maintenance will be a challenging task down the line.

Conclusion

To conclude, in a nutshell, keep your Gherkin (feature files) simple and business oriented. Focus more reusability in the internal layers of test automation architecture.

References:

Image Credits: inspiration png from pngtree.com