The Gherkin language allows the tester to write their own steps. This is a blessing (for flexibility) and a curse (for poor grammar). Although misspellings and out-of-place capitalization don’t affect the functionality of test scenarios, mixed point of view may cause ambiguity. Consider the following two examples:
Given I am at the Google search page When I search for “panda” Then I see web page links for “panda”
Given the browser is at the Google search page When the user searches for “panda” Then web page links for “panda” are shown
Both scenarios do the same thing: they run a basic Google search. However, the first one is written in first-person narrative, while the second one is written in third-person narrative. What happens when we mix the steps together?
Given I am at the Google search page When the user searches for “panda” Then I see web page links for “panda”
That scenario is confusing. Am I the user, or is the user a different person? Should there be a second browser for the user? Why do I see what the user sees? The English is poorly written due to the mixed point of view.
This may seem like a trivial example, but consider a project with multiple tests. Gherkin scenarios will reuse steps. Steps with different points of view will clash. Therefore, all Gherkin scenarios for a project should use one point of view.
So, which point of view is better? There is no definitively correct answer, but my strong conviction is that all Gherkin steps should use third-person perspective. Third-person perspective is entirely generic and can expressively name any user or system component. First-person semantically limits the expressive coverage of a step by forcing presumptions of who the speaker is. For example, if “I” am a user, what profile or privileges do I have? And are those attributes of who “I” am applicable when the step is used in other contexts? It may be easier to write Gherkin scenarios in first-person perspective because it helps the author to frame himself or herself in the context of the user, but it makes the steps less reusable. Even worse, first-person perspective can cause steps to be misunderstood. As a workaround, scenarios could add an extra “Given” step to explicitly frame the context of the first person (such as, “Given I am an administrator, When …”), but this requires an extra step that would be unnecessary with third-person perspective. Personally, I just don’t see the advantage to first-person point of view in Gherkin. And I would definitely reject code reviews that mixed the point of view either way.
As techies, we can look to the humanities for one more reason to use third-person point of view in Gherkin. In middle school, in high school, and in college, every teacher emphasized time and time again that essays must be written in third-person perspective. Every slip of “I think” and “I believe” and “you know” was dinged. Why? Third-person presents a more objective, more formal, and more powerful writing style. Gherkin is meant to be expressive, so let’s write it like we mean it.
Why not both? https://testzius.wordpress.com/2017/01/30/supercharging-your-step-definitions/
LikeLiked by 1 person
Awesome article. Makes me wonder if it shouldn’t be the business people writing the feature files? I don’t mean reading and discussing them with devs and testers, I mean actually writing them. Would that make sense?
LikeLiked by 1 person
Yes, absolutely. The whole point of Gherkin is to make requirements/acceptance criteria/tests understandable to all people, especially business people. In a perfectly behavior-driven Agile process, product owners would originate the feature files. In a more practical model, biz, dev, and test would join forces as “The Three Amigos” to write feature files.