When I first began writing Gherkin scenarios, I tended to use scenario names as labels. For example, I almost always started with:

Scenario: Happy Path

The subsequent scenarios would also often get a tag-like name. For example:

Scenario: Required fields

Scenario: Daylight savings time change

But, I have come to view scenario names as playing an important role in communicating to business stakeholders. They provide an opportunity to articulate a behavior concisely and in expressive business-oriented language.

In fact, I love to see scenario names written in such a way that, when the steps are collapsed out of view, the scenario names read well as a description of how the feature works. The collapsed view of the feature file becomes a valuable tool in communicating to certain audiences.

For example, on a recent project, we prepared scenarios for a new feature and began to review them with a key business stakeholder. It quickly became clear that he was finding the detail in the steps tedious. So, we collapsed all of the scenarios down to their titles. He was immediately more engaged, confirming scenarios and asking meaningful questions that gave rise to new scenarios. Of course, we still collaborated with other business stakeholders on the details in the steps. But, it was extremely helpful to have an intermediate level of detail that encouraged good communication.

Here is a simplified example. Do you find this list of collapsed scenario names more helpful?

Happy Path
Required Fields
Valid id format

Or, would you rather discuss these scenario names with a business stakeholder?

Creating a widget adds a new widget to the system
Prevent creating a widget unless the widget name and category are provided
Prevent creating a widget with an id that is too long

I believe scenario names deserve careful attention for the purpose of readability. Future posts in the Delightful Requirements series will offer suggestions for expressive, readable scenario names.