Especially when businesspeople lack the knowledge and technical vocabulary, communicating with software developers can often be a burdensome task. This is why we make use of user stories and the versatile system metaphor.
To streamline communication even further, however, we use a very clever piece of technology that can make this process even smoother — like a cucumber, one might say.

The Cucumber Framework

Cucumber is a BDD (or Behavior-Driven Development) framework that enables the creation of automated software tests — in an easy-to-write, and perfectly understandable way. But while many developers may not yet be well acquainted with this software tool, nearly all of them have dabbled with its popular child language.

What is the Gherkin language?

Cucumber uses Gherkin as a means to define use cases. At SPG, however, we primarily use it to generate unambiguous project requirements. The example below should serve to illustrate exactly what is meant by this:

Feature: The Current Account Holder withdraws money

Scenario: The account in question is not lacking in funds
Given the fact that the account balance is £200
And the debit card is valid
And the cash machine contains enough money
When the Current Account Holder requests £50
Then the cash machine should dispense £50
And the account balance should be £150
And the debit card should be returned
What are Gherkin keywords?
So to break it down into simpler terms, the Gherkin syntax makes use of five indispensable statements that together describe the actions which will be needed to perform a task:

Feature — denotes a high-level description of any given software function
Scenario — describes a concrete example
Given — explains the initial context of the system
When — specifies an event or action
Then — describes an expected outcome, or a result
And (or but) — increases text fluidity

By making use of these simple keywords, customers, analysts, testers and software programmers are empowered to exchange ideas with terminology recognisable by all.

Executable requirements & automated testing

Even better, Gherkin requirements are also executable. This is done by mapping each and every keyword to its intended (and clearly stated) functionality. So to keep with the example above, anything already implemented could automatically be displayed in green:

When the Current Account Holder requests £50
Then the cash machine should dispense £50
And the account balance should be £150
And the debit card should be returned

By extension, Gherkin enables developers to translate requirements into testable code. So in practice, you can use specific phrases to check in on your software solutions! If your current code isn’t working properly or a new change has accidentally caused a software error (or two or three), you can easily pinpoint problems before proceeding to repair them in a breeze.

Conclusion

Thanks to the Gherkin syntax, far from keeping our customers in a pickle, we can bridge the divide between businesses and developers and deliver outstanding products with greater confidence than ever before.