Writing good enough acceptance criteria used to drive me nuts. Some developers would complain it was too abstract, and others would say it was too prescriptive. I struggled to find balance.
One day, an experienced software engineer invited me for a coffee. I was curious about what he had to say, and he shared a way to provide enough guidance to the team. That’s how I learned about Gherkin. That transformed our collaboration for the better. I’m thankful for those magic ten minutes of chat.
Let me help you understand what Gherkin is about, how and when to use it, advantages and disadvantages.
Gherkin is a plain-text language with a simple structure. It enables a concise description of test scenarios and examples to illustrate business rules in real-world domains.
Some people call it cucumber, and others call it Gherkin. They mean the same 🙂
The goal is to give business scenarios a clear context and accelerate test automation. Gherkin uses simple keywords that can be quickly translated into automated tests and understood by non-programmers — “scenario,” “given,” “when,” “then,” and “but.”
A few things can be simpler than Gherkin. It uses the following keywords:
Let’s take an example of searching for apartments to rent:
Note that you can add “and” as a condition to complement the scenario. This scenario is simple to understand yet easy to translate into software engineering.
You may read all the above and ask, “Why should I bother?” This question depends a lot on your scenario. Product management doesn’t have anything that’s one-size-fits-all. That’s why you need to understand your business dynamics.
The above enables you to understand when to use it. I won’t enter into the nitty-gritty of backlog management here. That’s a talk for another coffee. Now, let’s talk about how you can combine Gherkin with product management.
My take is simple:
There are many ways of providing context. The most common ones are:
Given the continuous misunderstandings of the business context
When product managers say something
And misunderstandings take over
Then comes Gherkin handy because it’s simple
And creates an elegant bridge between business and tech
We’ve just used Gherkin to describe a real scenario =)
Circling back to the story I started, I used to write acceptance criteria before sharing the user stories with software engineers. Yet, they complained about the format and level of detail. Then, I started writing together with them. Although that improved, we still ran in circles.
Once I introduced Gherkin, I could give the context with my own words, and together we wrote down the scenarios. Contrary to what I initially thought, it accelerated our refinement and understanding.
Behavior-driven development, aka BDD, is an agile way of developing software. Mainly, it focuses on understanding user behaviors and how they relate to the experience of interacting with the application.
BDD has user behavior as the core of everything. And Gherkin is an excellent representation of it because it allows us to describe the behavior, action, and result. Let’s take ChatGPT as an example:
Scenario: beautifully asking for a salary increase
Given the user has the ChatGPT open
When the user requests ChatGPT to write a speech to convince the manager to give a 15 percent salary increase
Then ChatGPT drops a well elaborate message
By the way, I’ve just tried that, and it looked like this. Would that work?
Gherkin with BDD is a powerful combination to bring clarity and focus on users’ behaviors. This approach ensures predictable results and avoids confusion.
As with everything in life, you’d have advantages and disadvantages. Let me help you understand them.
If you start working with Gherkin, you will for sure benefit from the following:
Yet, not everything is smooth. Gherkin may bring some setbacks:
If you’ve opted to use Gherkin, the following practices will help you deliver better results:
Together, the product manager, software engineer, and product designer write scenarios. This is important to have different perspectives and create more concise scenarios.
Use the scenarios as starting points but embrace learning during the journey. You will uncover opportunities, share them, and develop new scenarios.
Some scenarios will turn out wrong, learn from them and adapt to other scenarios accordingly.
With BDD, we tend to think we know more than we do. Name assumptions, test them, and develop scenarios based on evidence, not opinions.
Gherkin and BDD are powerful because they provide guidance and clarity while reducing confusion. Yet, they may limit teams to execution. If you opt to use Gherkin and BDD, create space for innovation. Otherwise, you may fall prey to the build trap.
As stated in the Agile Manifesto in 2001, “Individuals and interactions over processes and tools.” Focus on collaboration instead of getting obsessed with tools. I’ve had many benefits with Gherkin but have seen teams obsessed with that and becoming blind to opportunities around them.
Remember that you’re the driver.
Gherkin and BDD should act as a tool to empower you to create value faster, but that should by no means limit teams’ creativity.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
In this article, we’ll discuss outcome-driven roadmaps and why they can actually be more efficient and productive than feature-driven ones.
MQ Qureshi talks about his experience with “unexpected sparks of brilliance” — solutions get to the core of what you’re trying to do.
A product review is the moment where you evaluate what the team created over the last development cycle and align on the next steps.