Cucumber - the world's most misunderstood collaboration tool

[aslak hellesoy]

I don't blog very often, but I did today:

https://cucumber.pro/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool.html

Aslak

[Jeff Nyman]

I still maintain that this is a battle that is not the right one to fight. Cucumber, and tools like it, absolutely are testing tools -- IF people realize that testing is both a design and an execution activity. Cucumber helps the former aspect of that, which is predicated upon communication and collaboration. This notion of an either-or dichotomy is a perfect example of the Tyranny of the Or.

Part of it, in my opinion, is also the name, which does nothing to brand itself. (I was heavily opinionated about that here -- http://testerstories.com/put-thought-into-naming-your-test-tools/. Even while I admit I probably made my own mistakes in that category.) It also doesn't help that "The Cucumber Book" repeatedly talks about Cucumber as if it were a testing tool, even using that exact terminology. Section 4.5 in the book has the sentence "Cucumber is a testing tool..." Given that many people learned about Cucumber from that book, it's hardly surprising how people view it.

All that said, I agree with this statement in your post: "When Cucumber is adopted solely as a tool to write automated tests without any input from business analysts they tend to become imperative and lose their documentation value."

I completely agree with that. However, using that as a way to say Cucumber is not (in part) a testing tool is where the discussion goes off the track for me. What you are saying with that quote is "When Cucumber is used solely as a test execution tool ..." What I'm saying is that the corollary would be: "When Cucumber is used as a test design tool ..." Requirements written as tests is an effective and efficient way to provide a shared notion of quality and a driver to development.

I agree that Cucumber is a collaboration tool. It's also a testing tool. People should be able to hold those ideas in their mind without conflict. What is required is a nuanced view of what testing entails. In my experience, it's the fact that Cucumber, and tools like it, try to set up a dichotomy that leads to conceptual problems. I've had opportunities to implement specification-by-example and test specification concepts (along with tools like Cucumber, Behat, SpecFlow, and Yadda) in hedge fund firms, clinical trial firms, banking firms, health insurance firms, decisioning-based ad serving firms, and even at Oracle (where they were dead set against the ideas initially). This was done by making it quite clear that such tools were, in part, testing tools -- but with the added focus that testing was a design activity, thus moving testing to the one phase where it often does the most good -- the initial communication and collaboration phase where ideas are elaborated.

[Scott Smith]

Nice commentary, Jeff!  Sounds like you and Aslak are in "violent agreement".  ;-)

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Scott Smith

http://twitter.com/_ofd (OldFartDeveloper)

[Roberto Lo Giacco]

While I'm not against your consideration, which I believe is correct, I personally keep repeating "Cucumber is not a test tool". Let me clarify though.

First, I'm not myself a tester, quality expert or have a career centered on quality. My job was always categorized as Developer, Programmer, Technical Architect, technical Director or such. Does that mean I don't know anything about quality?

I would say that Cucumber is a QA tool, not a test tool. It might be related to my context and my understanding of the `test` word, may be my experience about what `test design` means, but what I try to communicate with the sentence "Cucumber is not a test tool" is better worded with "Cucumber is not a replacement for JUnit, if you use it like that you'd better stop using Cucumber at all as you are actually writing much more `code` and adding a layer of indirection that you are not using and that actually makes your tests brittle and slower with absolutely no gain. On top of that you are going to submit questions on the Cucumber mailing list that are absolutely not related to Cucumber, but to the tools you are using within the step definitions, wasting the time of the community members".

Just the humble opinion from a developer who has always thought quality is part of development where testing is just the way to assert quality has been reached. In this wording Cucumber is a tool for quality that kicks in at the beginning through specs by example and helps obtaining executable tests.

I believe a good exercise is to write Gherkin feature files and give them to testers as test scenarios for manual testing.

I'm personally convinced Cucumber (or more generally BDD) adopters MUST understand this BEFORE moving in or ASAP otherwise it's like putting a donkey at the wheel of a Ferrari: you know the car will end in pieces.

My humble opinion, obviously.

[Matt Wynne]

On 6 Mar 2014, at 00:53, Jeff Nyman <jeff...@gmail.com> wrote:

> I agree that Cucumber is a collaboration tool. It's also a testing tool. People should be able to hold those ideas in their mind without conflict. What is required is a nuanced view of what testing entails. In my experience, it's the fact that Cucumber, and tools like it, try to set up a dichotomy that leads to conceptual problems. I've had opportunities to implement specification-by-example and test specification concepts (along with tools like Cucumber, Behat, SpecFlow, and Yadda) in hedge fund firms, clinical trial firms, banking firms, health insurance firms, decisioning-based ad serving firms, and even at Oracle (where they were dead set against the ideas initially). This was done by making it quite clear that such tools were, in part, testing tools -- but with the added focus that testing was a design activity, thus moving testing to the one phase where it often does the most good -- the initial communication and collaboration phase where ideas are elaborated.

Well said!