I'd like to enable the business analysts to be able to write all of their specs for features, scenarios and steps that is Cucumber friendly using Gherkin.
I've read some of the basic info on the github site for Cucumber and from doing a quick Google search but wanted to know if there were recommended resources for getting non-technical folks to be able to write comprehensive BDD using Gherkin (I assume that's the preferred language for Cucumber tests to be created in).
Thanks.
Gherkin is a plain-text language with a simple structure. It is designed to be easy to learn by non-programmers, yet structured enough to allow concise description of test scenarios and examples to illustrate business rules in most real-world domains.
Gherkin is a plain English text language, which helps the tool - Cucumber to interpret and execute the test scripts. One may think that, it has been discussed many times that Cucumber supports simple English text then why we need a separate language - Gherkins.
A gherkin is a pickled baby cucumber. The name “gherkin” comes from the Dutch word “gurken,” which means small pickled cucumber. Gherkins, also known as baby pickles or miniature cucumbers, are usually one to two inches long.
What I did with the business analysts in our company was to teach them the structure by giving them the keywords: Given, When, Then, And for Scenarios and In order to, As a and I want to for Features.
Then I gave them a simple example and told them to write down their own features as they thought they should be written. Surprisingly enough the structure was self explanatory and the features they wrote became a great start.
The only big problem was that they had contained to much logic in each scenario step. I solved that by iteratively asking "why?" which in most cases revealed the core functionality they were after and we re-wrote the scenarios accordantly.
By giving them the guidelines and letting them write the features themselves they got their hands dirty and were forced to think about what they wrote. Today they have a much better understanding and the "why?" iterations are not that common anymore.
Ofcourse you need to have the business analysts and the developers to work closely together and the features the analysts write should only act as a start. Remember that the Cucumber features are just a common language between the analysts and the developers. They still need to sit together often to be able to speak with each other :)
http://cukes.info is a great resource for teaching people how to write them. Ben Mabey also made a great presentation on Cucumber at Mountain West Ruby Conference 2009.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With