Gherkin, the language used in Cucumber to write tests, is meant to be understandable by folk from the business. I haven’t encountered product owners able to write their own scenarios. And I don’t trust either developers or testers to do it on their behalf. The only people I trust are business analysts trained to write and think Gherkin.
Product Owner
I recruit my product owners from the business so they are experts in Shipping, Banking, Journalism, Sales or whatever. But they are not software people. They might, more or less, know what they want but they struggle to articulate it let alone write it down in a way that can be automated in a test. I’m lucky if they can read the Gherkin but there is no way they’ll write scenarios.
Developer
I do not ask them to write the Gherkin scenarios. Developers think in code but Gherkin is not code. It should be business language. If your average developer writes the Gherkin scenario the best you’ll get is a badly written and poorly performing unit test. (Check out How to Stop Cucumber Becoming Technology Roadkill for a developers perspective on why developers shouldn’t write the Gherkin scenarios.)
I do get the developers to write the Cucumber step definitions. The bit that automates the Gherkin scenarios. That is proper code. Ruby, or Java or C# or whatever.
Tester
I have had automated testers and I’ve still have manual testers on my teams. Automated testers seem to like their own toolsets and aren’t attracted to Cucumber. So they are out. In fact I don’t bother including them on my team at all now days.
I do hire manual testers and I value them. But not for writing Gherkin scenarios. Any scenarios they write reflect the way these people test, i.e. by clicking through the application. That makes for terribly imperative scenarios, which are slow and brittle.
Business Analyst
I want people who understand the business, who think logically, and are comfortable with either a developer and tester hats on. I’ve only found this combination in business analysts. I train them in Gherkin and then let them loose.
This post is part of a series on Specification by Example.
References
Teese, B. (2012, 15 April). How to Stop Cucumber Becoming Technology Roadkill. Shine Technologies.
Hi!
I have been a business analyst for many years. Over the next 1-2 months, I and the team I manage plan to use gherkin to define requirements. Do you have any recommendations on where to start in terms of training and practice?
Thanks,
Hasangi
Here is a quick reply:
1. Read two books: Specification by Example and the Cucumber Book
2. Read my posts on it š
3. Get a coach
4. Start small. take a small example and work it through.
5. Get more than one person doing it so you can get different perspectives.
6. Agree a style – I recommend declarative but opinions differ
7. Remember to keep the Gherkin clean and push nasty implementation details to the Step Definitions
Let me know how you get on.
S
Our team has been using Gherkin to capture requirements and Cucumber to generate tests for a couple of years. Used on four small-ish projects now and starting our fifth. With each project we’ve refined our skills and overall it’s cut costs and time and won the hearts of the business members of our team. We’ve found that all of the team members are able to contribute in some measure to the feature scenarios because each brings their own particular perspective. One thing I’ve noticed is that it’s a constant fight to keep the Feature file purely in the business domain. If people don’t get that, then they shouldn’t be writing Features.
“people who understand the business, who think logically, and are comfortable with either a developer and tester hats on”.. We have found Testers and Devs and BAs who fit your criteria,
cheers,
Bernie, you are right. It isn’t only BAs that fit that criteria. I’ve just found it very hard for normal Devs to learn the style (they easily revert to unit test style) and hard for manual testers (who rely on the UI in their day job). Harder/hard, but not impossible. BAs seem to find it easier to get the style.