If you’re thinking of a cucumber, the answer is yes! Let me tell you all about it.
What is Cucumber?
Cucumber is a tool that utilizes a syntax called Gherkin, which makes acceptance criteria and test cases accessible to all interested stakeholders, technical and not so technical alike. The official documentation explains Cucumber like so:
That sounds cool, but what is that Gherkin thing you mentioned?
Gherkin is a plain English, human-readable syntax that defines who the audience is, what action is to be taken, and what the expected outcome should be. It looks something like this:
Given I am a user on Google
When I search for “how wonderful is the Gherkin language?”
hen I should be directed to the “Google Search Results” page
And I should see "how wonderful is the Gherkin language?" in the search field
This use case is pretty self-explanatory, right? That is the point! The really simple, easy-to-understand, self-explanatory point.
I’m liking what I’m reading but I don’t quite understand what this has to do with quality assurance…
Quality assurance is all about ensuring the feature that is being developed is what the stakeholders (business analysts, product owners, etc.) asked for. Gherkin provides a means for said stakeholders to define what they want as acceptance criteria which the development and QA teams can digest to determine whether the end result matches what was intended.
Generally, the business analysts will not provide every individual use case so this is where QA comes in. QA can take the high-level acceptance criteria and come up with all the various lower-level test cases. These test cases can also be written in Gherkin syntax. This provides some stellar benefits:
- Test cases become visible and accessible – anyone on the team, technical or not, can read through the test cases and understand what is being tested
- Test cases written in this way encourage test case review sessions with your team – when everyone in the audience is able to be on the same page and not get bogged down by technical details, it is easier to keep an objective view of what the feature under test is expected to do, which promotes communication. With the test cases defined in plain English, oftentimes it brings up questions that weren’t previously considered that require the feature to be changed
- When the stakeholders provide acceptance criteria, test cases can be written in tandem, or even prior to, development – as per the point above, if changes need to be made they can be caught early during test case review sessions, before development is complete
- These test cases will act as documentation for the feature under test – no more relying on one person to explain how some part of the system works, no more needing to spend hours explaining to a new hire how the product works, no more having to remember to go back and update wikis when features get updated (more on this in a moment) – of course the self-documenting nature of Gherkin won’t completely eliminate the above but it should greatly reduce the time spent
Back to Cucumber. Remember Cucumber?
The test cases written in Gherkin are written in what is called a feature file, which is basically a plain text file but it is consumable by Cucumber. Cucumber has bindings in several different coding languages which allows those test cases to become automated test cases. Without getting too deep into the specifics of how to implement Cucumber, each of the steps (Given, When, Then) from the Gherkin scenarios gets translated into code that programmatically achieves the step. For example, Given I am a user on Google will have a step definition implementation that will open a browser and load google.com. From a technical point of view there are additional tools that are required to achieve this but that is for another blog post!
One of the nice collaborative things about Gherkin/Cucumber is you can have one person write out all the test cases in the feature file and have a different person implement the automated code for each test case. This may be beneficial if your team has someone who perhaps is less technical or doesn’t have the time capacity to write the automation him or herself who can be responsible for test case writing, and perhaps you have someone else who is more technically-savvy but not as strong in coming up with test cases who can be responsible for developing the automation. Of course you can also have a single person responsible for both the test case writing and test automation development and execution. The point is Gherkin/Cucumber provides resource flexibility.
So with Cucumber those test cases that were written in Gherkin become automatically executable! They should not require tests to be run manually. That is yet another benefit of Cucumber: you define the tests once and they can be run repeatedly. Those wonderful Gherkin tests that were written during feature development then go on to become part of the regression suite, which can be run with a click of a button thanks to the automation integration with Cucumber. If a feature ends up changing but perhaps the QA team was not informed, it will become evident because one or more tests will fail. This should prompt conversation and either a change was unintentionally made or it was made intentionally and the test case – which is also acting as feature documentation, keep in mind – gets updated so the tests pass again.
I’m intrigued and want to learn more!
Glad to hear it! Please check out these helpful resources:
- Official Cucumber website
- Cucumber book (with examples in Ruby)
- Cucumber book (with examples in Java)
- Google / YouTube search “cucumber tool” to find more helpful resources, tutorials and examples in one of the many language bindings supported by Cucumber
*may technically be considered a fruit