Good Gherkin Scenario Titles

Don’t know about Behavior-Driven Development or Gherkin? Start here!

The Golden Gherkin Rule states:

Treat other readers as you would want to be treated. Write Gherkin so that people who don’t know the feature will understand it.

Part of writing good Gherkin (or any other specification-by-example language) includes writing good behavior scenario titles. The title is the face of the scenario: it summarizes what the behavior is all about. Good titles make collaboration and test triage a breeze, whereas bad titles make it tougher. But what makes a title “good”? Below are some helpful pointers.

Good Titles from Good Tests

Writing good titles is easy for well-written scenarios. A good Gherkin scenario concisely focuses on one distinct behavior. If you are struggling to think of a good title, perhaps you should take a step back and ask, “Is this scenario a good scenario?” Check out my article, 4 Rules for Writing Good Gherkin, or Paul Merrill’s article, 5 ways to simplify your automated test cases, to help you write great scenarios.


Good titles should be short one-liners. One simple statement should be sufficient to concisely capture the intended behavior. Anything longer likely means that either the author doesn’t truly understand the behavior in focus, or that the scenario does not focus on one main behavior. Extra comments may be added to supplement the scenario’s description if necessary to avoid lengthy titles. Also, most BDD test automation frameworks will print scenario titles to logs for traceability.

Bad ExampleGood Example
The user can log into the app, navigate to the profile page, and see their full name, address, phone number, email, and usernameThe profile page displays the user’s personal info

Conjunction Disjunction

Watch out for conjunction words like “and,” “or,” and “but.” Conjunctions typically imply that more than one thing will be done, which for scenario titles implies that more than one behavior will be covered. Or, it indicates that a Scenario Outline may be appropriate Don’t break the Cardinal Rule of BDD! Keep each scenario focused on one main behavior.

Avoid other conjunctions like “because,” “since,” and “so” as well. Phrases starting with those words often give an explanation for why the scenario exists. However, for conciseness, scenario titles should focus on what the behavior is. The why can either be deduced from the steps or made plain with comments.

Bad ExampleGood Example
The user can request an insurance quote from the big “Get-A-Quote” button on the home page or from the “Insurance Policies” pageTwo Scenarios: The user requests an insurance quote from the “Get-A-Quote” button on the home page / The user requests an insurance quote from the “Insurance Policies” page



Scenario Outline: The user requests an insurance quote

The last five search phrases are saved so that the user can rerun them from the history pageThe history page saves the last five search phrases

Avoid Assertion Language

Don’t use the words “verify,” “assert,” or “should” in scenario titles. They put the scenario’s emphasis on the assertion rather than the behavior. Assertions are merely a facet of behavior testing – they verify that something exists or that two values are equal. Behavior scenarios, however, are full software specifications. BDD is a development practice for making better software products – it’s not just a test tool. Don’t reduce the behavior-driven mindset to a test-only mindset.

Furthermore, leading every scenario title with “verify” or “assert” becomes very repetitive. The words just don’t enhance the meaningfulness of the title. They also thwart alphabetical order.

Bad ExampleGood Example
Verify the user can change their address on the profile pageProfile page address change
Assert that a stock quote is displayed in green text when its value is higher than its previous closing valueA stock quote has green text when its value is higher than its previous closing value
The goodbye page should be displayed after a successful logoutLogout displays the goodbye page

Do you have any more suggestions? Put them in the comments below!


  1. Hey Andy, how are you? I’ve been followed your blog so today I’d like to know what references you usually read to write great posts. Could you recommend a book? 🙂


    1. Hi there! Thanks for reading. To be honest, most of my blog material comes from my own experiences using the tools, frameworks, and practices. For example, that’s how I came up with my own good Gherkin guidelines. For technical information (like settings in a test framework) I simply run Google searches, find answers either from online doc or from other people, and give them a try. I always try to embed links in my articles to any sources I used to learn info. My blog posts act as my own notes, in a sense.

      I don’t have any particular book I frequently cite or use consistently as a guide. The official Cucumber book is pretty good, though.

      Liked by 1 person

  2. Hey Andy, what about positive and negative bdd scenarios? Separating them is one (good or bad?) thing, but what about finding good scenario titles after separation?


      1. Of course, and sorry for the delay. A more generic example of what I meant:
        We usually tend to separate examples/scenarios in one successful scenario (even naming it ‘successful’) and some error examples.

        Scenario: Successful reading of some documents
        G / W / T

        Scenario Outline: Unsuccesful reading of some documents
        G / W / T
        | … | … | notes |
        | … | … | no docs available |
        | … | … | no rights to read docs |
        | … | … | too much docs to read |

        Is it good or bad practice to do this?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s