I've been bringing Cucumber testing to my team for about a year, as a
software engineer - turned - technical tester. I started out writing
features and then implementing the steps myself, but I knew something was
missing when I did that: the knowledge and the expectations of a business
analyst. I knew they would have different ideas about how we should expect
the system to work, and express that differently, and that would likely
drive a conversation which would enlighten both of us. Most importantly,
just because they would do things differently didn't mean I could also do
it my way by adding extra scenarios.
So I recently got the BAs involved in writing Cucumber scenarios. They used
to write fairly loose acceptance criteria, sometimes organised into a table
of "When I do this/This happens" where the first column was really a
disguised Given/When. Their first attempts at writing features ended up out
of order, very verbose (they didn't know how to use tables, and just
copy/pasted), and as a result were very difficult to read and separate out
what the difference was. This required rework by myself and the developers,
to put them in proper Given/When/Then order, which meant overall it had
taken more time to specify and understand the requirements. And then I had
to distill those, make them more concise Example tables, and implement them
So the first attempt didn't go too well, but we learned from that. We
learned for one thing that Given/When/Then is actually not the best or most
concise way to specify requirements in all cases, that the old table might
be better. And the BAs are getting better at writing what is actually
But more importantly, in one instance, the developers added a test which
they thought was intended behaviour. The BA read this and disagreed. So
there was a discussion and we determined what was actually intended, and
wrote that as a set of scenarios. This required a code change, which
already had tests which the BA could read and agree to. Had this been
written as a Java test, the BA would not have noticed, and it would have
been signed off and released that way, and it would work differently from
how the BA thought it did or intended it to.
Of course, the BAs don't write perfect tests, because they want to describe
how things should work when they do work. They don't always think about
error conditions, what it should do when it fails, or edge cases like empty
or bad input. That's what I and/or the developers are here for. There are
still unit and integration tests under the hood, but we can also add error
conditions to our human-readable behaviour tests, which can test that a
certain job says "FAILED" when it should, and that shows up in this report,
which BAs and customers read. If a customer is going to be seeing the
output, they should be able to read and validate the specification, not
just the rough description which they submitted. Or at least, the BA can do
so on their behalf, and clarify it with them if required.
It would be worth revisiting this in 6 months to see how things are going.
By then we might have progressed to the developers also helping implement
steps as part of the story, making the loop tighter and avoiding test
duplication. I would also like to hear from other teams who have integrated
cucumber into their whole process, not just as a developer tool.
Hope this helps.
Post by Matt Wynne
A few weeks ago, a well-kown open-source contributor wrote a blog post
discussing some of his predictably controversial attitudes to test-driven
Dont use Cucumber unless you live in the magic kingdom of
non-programmers-writing-tests (and send me a bottle of fairy dust if
Of course he's missed the point slightly: in my magic kingdom
non-programmers don't write tests, they *collaborate with* programmers to
write tests. And then they read them, safe in the knowledge that they're
accurate. But I digress.
The magic kingdom does indeed exist, and I love to spend time there. I bet
you do to. I want the world to know how wonderful our magic kingdom is, and
I need your help. I'd like some real quotes from real people who have
experienced the value of using business-readable Cucumber tests as part of
their development workflow.
Can you tell me a story about your magic kingdom? Do non-programmers
REALLY collaborate with programmers to write tests? GOSH! Can you tell me a
little bit about what that's like?
Thanks in advance.
sorry if you've got this twice)
Freelance programmer & coach
-- Rules --
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
You received this message because you are subscribed to the Google Groups Cukes group. To post to this group, send email to cukes-/JYPxA39Uh5TLH3MbocFF+Gfirstname.lastname@example.org To unsubscribe from this group, send email to email@example.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en