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.
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.
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.
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.
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.
Teese, B. (2012, 15 April). How to Stop Cucumber Becoming Technology Roadkill. Shine Technologies.