By Line Karkov, Senior Business Analyst at DM – fagforening
The first time I attempted using specification by example, I failed. A couple of years ago, I was the product owner for a development team of external developers from a consulting company.
The team suggested that we automate the acceptance tests using Gherkin, because they had done so with other customers with success. So, I read “Writing Great Specifications” by Kamil Nicieja, and I realized that it had great potential for improving the quality of the requirements and the collaboration with the team. But when I wanted to discuss with them how to shake up the refinement process based on the Gherkin specification, they did not understand what I was talking about. And when I handed them the Gherkin files I had written based on what I had read in a 200-page long book, they said my specifications did not follow best practice. They didn’t know how to create test scripts based on my files and could not direct me towards a best practice they preferred. Nothing came of it.
Nonetheless, it is now my favorite approach to requirements specification. This is because specification by example is not supposed to be generic – rather it is intended to be representative and specific. That difference is quite substantial. First of all, conversations change. Conversations with business stakeholders about what an example looks like is an easy way to get into details about who does what, when and why. Conversations with developers focus more on what matters to the business. If I cannot come up with an example to some theoretical issue that the dev team comes up with, it is not important. Second of all, it is a more efficient way for me to work as a business analyst and product owner. When the Gherkin scenarios are written, I have also defined what needs to be acceptance tested and how. So, my key to success with Gherkin was to focus on the format as a method for requirements specification and detach the automation of acceptance testing.
What is specification by example and Gherkin? Gherkin is a specific format that can be used to write your requirements as examples. It structures a number of a scenarios in a feature. The scenarios are all structured according to a Given, When, Then format, and possibly with examples added.
Watch Line Karkov live at the Business Analysis Conference, 19 – 21 September 2022. View the full agenda, speakers and register at https://irmuk.co.uk/events/business-analysis-conference-europe/
Something like this:
Given: that Susan is reading “Specification by example” on IRM Connect
When: she writes a comment to the post
Then: all others reader of the post can read the comment
Examples: Name and e-mail are required fields
The examples are part of the scenario. They can be expanded to include validation rules, in this case it could be a valid e-mail and max number of characters for the comment. If this scenario includes the only requirements related to commenting blog posts, then this would be the only scenario in a feature called “Commenting blog posts”. Additional scenarios can be added to the feature – e.g., that Susan edits or deletes a comment, a moderator deletes a comment, or another reader writes a comment to Susan´s comment.
Gherkin specifications fit well together with a product backlog and user stories. This is how I integrate Gherkin specifications with my product backlog:
- Identify the features: This is the scope of the product
- Identify the scenarios: The product backlog can be established with users stories, and the features prioritized
- Describe the scenario: Now the user stories can be prioritized
- Add example data to the scenarios: The user story is ready for development
Scenarios with examples like these can be used as acceptance criteria for your user stories. Because of the structure of the scenarios, they can be used as test cases for manual tests, and the examples then specify which test data is required. In conclusion, you will have acceptance criteria that can be tested.
I am glad that I gave Gherkin a second chance, even if I never manage to automate a single acceptance test case.