The Ultimate Combination Of Feature Files And Gherkin

by TestFortExpert on 07/30/2014

This Post’s Beginner terminology

Gherkin – basically a small computer language with a well-defined syntax. A format of Cucumber specifications.
Gherkin scenario – One of the basic Gherkin structures. Each feature may have several scenarios.
Gherkin file – a feature file containing Gherkin scenarios.
Epic (feature level requirements) – multiple User Stories including requirement of high level.

Let’s get to business.

Quality assurance is a huge field with lots of tricks. Here is one of such. Now that we are done with terminology that will be used in this post we may get going with our combinations. Now we are getting to the question that matters. Where do we put gherkin scenarios?

Let’s say we have a User Story written in cucumber. That user story came with associated Gherkin (G) scenarios. So the main question is on where to put each scenario. The Bugs take place due to human nature. Programmers for some reason, known to them only (I don’t even know whether it’s psychological or intuitive) tend to associate every User Story to a separate G file. So your team is performing some test-first development. They will start writing Gherkin scenarios the moment their hands reach the User Story. Thus it will be nothing but natural to place these scenarios inside a new G file.

Account

The Ultimate Combination Of Feature Files And Gherkin

You can see an Epic ‘search for customers’ in this example. It has three user stories: the search by name, address, account number. It is possible for each User story to get a personal G file, let’s say a search-by-name feature. This is an easy way to go, yet even an easier way to get involved with some trouble. The user stories will demand some updates into the Gherkin scenarios and voila – your team is in a mess. User Stories are something like a very thin vertical slice that is going through the system. And they will certainly be rapidly followed by other exact same slices in the very same area. Having different G files makes the fact that all the functionality is being related at some higher level quite blurry.

That is but one example of making testing more complicated. Or simpler. Depends on the way you’ll be looking at things.

We Work With

Having one outside team deal with every aspect of quality assurance on your software project saves you time and money on creating an in-house QA department. We have dedicated testing engineers with years of experience, and here is what they can help you with.

Software is everywhere around us, and it’s essential for your testing team to be familiar with all the various types and platforms software can come with. In 21+ years, our QA team has tested every type of software there is, and here are some of their specialties.

There are dozens of different types of testing, but it takes a team of experts to know which ones are relevant to your software project and how to include them in the testing strategy the right way. These are just some of the testing types our QA engineers excel in.

The success of a software project depends, among other things, on whether it’s the right fit for the industry it’s in. And that is true not just for the development stage, but also for QA. Different industry have different software requirements, and our team knows all about them.

Full-Cycle Services

By Platform

By Type

Industries