Hi,
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.
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.
Having just worked on an agile project using cucumber for the first time I think that the best way to learn cucumber and gerkin is to get your hands dirty.
I may be wrong but I get the impression from your question you are wanting to train your BAs to write gerkin then they will write a bunch of features and hand them to developers.
This is definitely not the way to go. It is much better to have BA's devs and users (if possible) working together to write your scenarios and build them as you go. Then you all learn together what works and what doesn't.
We tried having a BA write entire features and hand them over. We (the devs) ended up having to do major rewrites because the implementation ended up different to that originally envisioned by the BA. We also had to change the syntax of the steps and do find and replace through the whole file.
Do one scenario at a time, get it working then move on to the next. An iterative approach reduces wasted effort and makes sure you all understand how you want the app to behave.
In terms of how to write steps it is best to start with the ones that come with cucumber and copy and adapt them as you work on your project to fit your particular application. There is no right or wrong, it is what works for you. The documentation on the cucumber sites is generally good and will be a valuable resource as you learn more.
What I did with the business analysts in our company was to learn 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 :)
We are teaching Gherkin (for SpecFlow) in a similar way, how mrD has described it.
I think it is very important though, that the audience is familiar with the main intention of "Specification by Example", agile requirement analysis and BDD, so we usually start discussing the background first. We also show a sample Gherkin scenario and explain the very basics (like Given/When/Then/But and tables).
Than we take a simple example story (that is quite familiar to everyone), like "add items to shopping cart" (with some orientation, of course) and let them formulate the acceptance criteria in small groups.
After that every team shows / explains their solutions and we discuss the good and bad practices that were present. After the second team, you can see almost all of the most important (good or bad) practices appearing.
I also type in the concluded solution, and show here alternative ways of describing the scenarios (background, scenario outline, etc.). If there is enough time, I also show how to automate & implement the imagined functionality based on that. This also help to understand some important rules to follow, that makes the automation much easier.
Although, I never know upfront what will happen, usually this exercise is the best part of our BDD training.