Let’s make Developers’ life easy. Want to know How?

We will first see what is TDD. TDD abbreviates for Test driven development. It differs from traditional testing method as it is a concept of doing testing before even development starts. Sounds weird? Let’s see how.

Testers write the test cases based on the business requirement documents. Developers then build the code based on the testcases. Some test cases might fail as the coding gradually widens. Later the code is again re-worked by the developers to make the test cases pass. This gives the luxury to developers that they can feel confident that their code does the job the way how it was designed.

Below is the lifecycle of TDD in real scenario.

So where does BDD comes into picture? Here you are. BDD comes as a savior in the life of a Business owners/analysts, Testers and developers. BDD is a Behavior driven development where behavior of the particular event is written in a simple English vocabulary. BDD uses test scripts called Gherkin. Gherkin is a simple domain specific language written in plain English. It provides Business analysts/testers with writing the behavior of the use cases without the logic/implementation details.

Gherkin Syntax:

Gherkin uses 5 simple syntax. It is mostly event oriented in which each event has to have a feature and a scenario.

Feature: Describes what action is impacted in a particular module.

Scenario: Describes the whole event.

Given: Describes where the user is in

When: Describes the click action of the user

Then: describes the outcome of the click action

There are also other couple of syntax which are “And” which is used in the composite Gherkin and “But” which is used rarely

It is always good to write the testcases in its most granular level which means you break it down to the step that it could be no more granulated.

Let’s relate this to an example of adding a food item to the McDonald's cart

Feature: Online Food ordering system in McD

Scenario: Adding an item to the cart

Given: the user is in the “view menu”

When: the user clicks on the burger

Then: burger gets added to the cart.

Hope we had enough with the feature of gherkin and here we go with the benefits of Gherkin, as selling a product involves more of explaining the benefits to the end customer rather than explaining just the feature.

How does it help the testers/BAs?

• Language is plain English.

• Can communicate easily with developers

• Could be easily implemented in Agile projects

How does it help the developers?

• Developers can easily track the work completion in each module

• Can quickly segregate the issue as one event = one gherkin script

• Can break the entire user story to a small agile project and be completed in a day.

• Very solid document to start their coding

Let’s also quickly see where this part of Gherkin fits into the Software lifecycle. There is a hugely evolving position in the IT industry today, called as SDET’s. SDETs are software development engineer in Test. These SDETS will do the automation of all the Gherkin scripts using the automation tool called CUCUMBER. Cucumber has the ability to understand the Gherkin tests and validates the code performance as it should. It automates the code for acceptance testing.

I will continue exploring more on SDET and CUCUMBER in my upcoming blog.