[cucumber-rails] Suggestion that cucumber is no longer used in rails

[Kosmas]

Taken from the Manning Publications book 'Rails 4 In Action' there is a suggestion that the rails community has moved away from cucumber:

BDD is a methodology based on TDD. You write an automated test to check the interaction between the different parts of the codebase rather than testing that
each part works independently.
Two tools used for BDD when building Rails applications are RSpec and 3Cucumber, with this book heavily relying on RSpec and foregoing Cucumber .

Footnote 3 mCucumber was previously used in earlier editions of this book, but the community has drifted away from using it,
as there are other tools (like Capybara, mentioned later) that provide a very similar way to test, but in a much neater syntax.

There was also a blog post about it here:

http://blog.8thlight.com/kevin-liddle/2013/09/18/a-case-against-cucumber.html

Any ideas/suggestions if we could do anything?

[aslak hellesoy]

I'm working on a blog post. I (and a lot of others) have been trying to explain this for years, but it's an uphill battle.

We clearly need to continue to spread this message to stop people from getting the wrong impression.

The gist of it is that contrary to popular belief, Cucumber was never meant to be a testing tool,

but a communication/collaboration tool.

When people see something new they don't recognise or understand they will always try to figure out what it is similar to.

Cucumber is similar to a testing tool. So people have started to use it as a testing tool.

Of course, it is terrible at that. Because it wasn't meant to be a testing tool.

If people stop using Cucumber for what it was never meant to be used for, that's a good thing.

It doesn't serve the projects who need a testing tool, and it doesn't serve the Cucumber tool's reputation.

To those of you who have no idea what the heck I'm talking about, just hang in there for the blog post.

Aslak

--
-- 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 cu...@googlegroups.com. To unsubscribe from this group, send email to cukes+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en
---
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]

I also read the above blog post yesterday.  It's interesting because, while he has some good points, he misses important considerations for the long term.

Anyways, here's where I agree with him:

1. Absolutely agree with him that, if you have no product manager or stakeholder who will read (and help generate/review) the cukes, then writing them is a complete waste of time; instead write tests in your favorite TDD framework.
2. Absolutely agree with him that Gherkin is a very useful technique to flesh out the requirements.
3. Absolutely agree with him that there is a learning curve/overhead in using Cucumber to drive your tests:
1. Learning to write step-definitions.
2. Learning how to turn tests on and off (tagging).
3. Learning how to use Cucumber for both driving browsers (i.e. Capybara/Selenium-WebDriver/etc) vs in-code testing (directly testing business rules).
4. Agree with him that obvious requirements don't need to be cuke'd.

So where are my disagreements?

1. Over the long haul, a comprehensive Cucumber suite provides an easy-to-access reference to what a complex system is required to do.  Without it:
1. Dead code lingers on because there is no easy way to tell whether it is needed or not.
2. Harder to identify which code matches required functionality because required functionality is not tracked.
3. TDD implementations are a mix of unit, functional, integration, and smoke tests; organizing them so that functional requirements are separated out is challenging.  It takes a special additional discipline to organize this and make the TDD tests readable for non-technical people to make this work.
2. My own experience is that the lack of this will cause a Rails system to become brittle over time.  More and more time is spent trying to remember what the system is supposed to be doing.
   
3. Not tying the cukes through step definitions to automate the tests means that the cukes are simply one more piece of documentation that gets out of date.  Inaccurate documentation, Gherkin-based or not, is as perilous as dead code.

The Rails approach promotes the idea that the code itself is the reference.  Many "agilistias" support this notion.  Which is acceptable as long as the code is self-explanatory.

But it's when the code repeatedly changes that things get confusing.  What's current?  What's no longer current?  One of the great banes of life for this developer is attempting to debug code that no longer has any functionality in the system.

If functionality never changed for a Rails system but only grew, I'm guessing that you would probably not need Cucumber.  But I haven't found "only growing" to be reality; functionality is discarded and/or modified.

There is no easy way to track functionality changes, but it's exceedingly important for a maintainable complex system.  In our organization, we have gone back and forth between Cucumber and other strategies, and Cucumber wins out.  If we can't explain important business functionality in a Cucumber, and we can't tie that Cucumber Gherkin code to automatically run regression tests for those features, then the organization hasn't done its job.  Cucumber forces us to "think it through".

That being said, it has been tempting to "short-circuit" Cucumber and, too often, not use it fully (or not at all).  In such circumstances, it has cost us:

1. A couple of developers have accumulated very high "bus numbers".  They have way too much of the business logic in their heads, and increasingly they can't even remember what's current.  
2. New developers are slowed down by not having the information in a reliably-maintained set of external requirements.
3. Product managers have a difficult time communicating when a cuke-precise document isn't available to collaborate around.
4. As a result, much time is spent
1. Trying to determine requirements.
2. Debugging at the system level rather than at the unit level.
3. Figuring out what code should be removed.
4. Tracking down and correcting bad data.
5. and as a result, it has become increasingly difficult to accurately project sprint velocity in areas where we haven't been 'cuke-diligent'.
   

So our struggle is to use Cucumber to flesh out business requirements and to attach those to automated regression tests.  When we use it, life is good.  When we don't, well...

--
-- 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 cu...@googlegroups.com. To unsubscribe from this group, send email to cukes+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en
---
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

[Tom Cloyd]

Just want to say that for this rank amateur this conversation is
utterly fascinating, and also very helpful. I'm very appreciative for
getting to listen in.

I write stuff just for myself, but may not look at the code for months
at a time. Getting Cucumber involved looks like a very good idea in
this situation. We'll see, as the months roll by.

[Robert]

On Saturday, September 21, 2013 12:13:31 PM UTC-7, Aslak Hellesøy wrote:

On Sat, Sep 21, 2013 at 6:31 PM, Kosmas <kos...@gmail.com> wrote:

Taken from the Manning Publications book 'Rails 4 In Action' there is a suggestion that the rails community has moved away from cucumber:

BDD is a methodology based on TDD. You write an automated test to check the interaction between the different parts of the codebase rather than testing that
each part works independently.
Two tools used for BDD when building Rails applications are RSpec and 3Cucumber, with this book heavily relying on RSpec and foregoing Cucumber .

Footnote 3 mCucumber was previously used in earlier editions of this book, but the community has drifted away from using it,
as there are other tools (like Capybara, mentioned later) that provide a very similar way to test, but in a much neater syntax.

There was also a blog post about it here:

http://blog.8thlight.com/kevin-liddle/2013/09/18/a-case-against-cucumber.html

Any ideas/suggestions if we could do anything?

I'm working on a blog post. I (and a lot of others) have been trying to explain this for years, but it's an uphill battle.

We clearly need to continue to spread this message to stop people from getting the wrong impression.

The gist of it is that contrary to popular belief, Cucumber was never meant to be a testing tool,

but a communication/collaboration tool.

When people see something new they don't recognise or understand they will always try to figure out what it is similar to.

Cucumber is similar to a testing tool. So people have started to use it as a testing tool.

Of course, it is terrible at that. Because it wasn't meant to be a testing tool.

If people stop using Cucumber for what it was never meant to be used for, that's a good thing.

It doesn't serve the projects who need a testing tool, and it doesn't serve the Cucumber tool's reputation.

To those of you who have no idea what the heck I'm talking about, just hang in there for the blog post.

Aslak

Aslak,

I eagerly await for your blog post.  

Originally, I was attracted to cucumber as a means of automating a number of my tests (QA tester here).  However, over time, it became more and more evident to me as I moved away from imperative steps to declarative steps and began working closer with the devs and product owners, that cucumber was much more use to me as a means of communicating.  Even if we did not implement a single step definition, the value of defining the scenarios using Gherkin and being able to work collaboratively with our devs and product owners is a huge win for us.

[aslak hellesoy]

Thanks for sharing Robert,

It's great to hear you have found a way that works - it does indeed sound like they way I wish everyone had found.

Aslak

[Jon Kern]

This discussion and blog post reminds me of why I grew weary of trying to "win over" people who decried the use of agile methods, and went on to explain reasoning that clearly demonstrated (to me, anyway), a deep lack of understanding. 

It is much like putting up your own "straw man" argument, and then winning the argument -- only the entire premise is incorrect.

I found the blog post amateur and totally missing the point of how one could use and benefit from Cucumber.

As I write here: http://technicaldebt.com/?page_id=1341

"There are naysayers of using Cucumber. But like any tool, you have to know how to use it. A fool with a tool is still a fool."

disclaimer: I fell in love with Cucumber from the moment I started using it, and have never been disappointed.

Jon Kern

blog: http://technicaldebt.com

twitter: http://twitter.com/JonKernPA

[byrnejb]

On Saturday, 21 September 2013 16:27:57 UTC-4, oldfartdeveloper wrote:

I also read the above blog post yesterday.  It's interesting because, while he has some good points, he misses important considerations for the long term.

Anyways, here's where I agree with him:

1. Absolutely agree with him that, if you have no product manager or stakeholder who will read (and help generate/review) the cukes, then writing them is a complete waste of time; instead write tests in your favorite TDD framework.

I disagree with this point.  When exploring the problem domain writing out cukes  forces one to confront imperfectly understood, or completely overlooked, areaas requiring further attention.  Writing tests directly in this case puts ones eyes and thought down in the weeds, when it might be a different field that needs mowing.

1. Absolutely agree with him that Gherkin is a very useful technique to flesh out the requirements.
2. Absolutely agree with him that there is a learning curve/overhead in using Cucumber to drive your tests:

. . .

1. Agree with him that obvious requirements don't need to be cuke'd.

I disagree with this position too. What is obvious on one day often disappears from view on another and all too frequently is only rediscovered after some considerable effort. It is best to be comprehensive even if it covers the 'obvious'.
 

So where are my disagreements?

1. Over the long haul, a comprehensive Cucumber suite provides an easy-to-access reference to what a complex system is required to do.  Without it:
1. Dead code lingers on because there is no easy way to tell whether it is needed or not.
2. Harder to identify which code matches required functionality because required functionality is not tracked.
3. TDD implementations are a mix of unit, functional, integration, and smoke tests; organizing them so that functional requirements are separated out is challenging.  It takes a special additional discipline to organize this and make the TDD tests readable for non-technical people to make this work.
2. My own experience is that the lack of this will cause a Rails system to become brittle over time.  More and more time is spent trying to remember what the system is supposed to be doing.
   
3. Not tying the cukes through step definitions to automate the tests means that the cukes are simply one more piece of documentation that gets out of date.  Inaccurate documentation, Gherkin-based or not, is as perilous as dead code.

Agree entirely.  This is the major benefit I have obtained from Cucumber.  it 'works' or 'stresses' the documentation as well as the code.

The Rails approach promotes the idea that the code itself is the reference.  Many "agilistias" support this notion.  Which is acceptable as long as the code is self-explanatory.

 

I have always considered this professed belief in the self-documenting nature of code to be at best a pious fraud.  It begins with the implicit assumption that the maintainer is both a Ruby language expert and current with the idiom is vogue at the time the code was originally written.  It is also premised, in my observation, on the untenable position that one is intimately familiar with the code stack.  In a maintenance situation, where one may be supporting old code in a half-a-dozen different languages this is seldom the case.

But it's when the code repeatedly changes that things get confusing.  What's current?  What's no longer current?  One of the great banes of life for this developer is attempting to debug code that no longer has any functionality in the system.

Concur.

If functionality never changed for a Rails system but only grew, I'm guessing that you would probably not need Cucumber.  But I haven't found "only growing" to be reality; functionality is discarded and/or modified.

There is no easy way to track functionality changes, but it's exceedingly important for a maintainable complex system.  In our organization, we have gone back and forth between Cucumber and other strategies, and Cucumber wins out.  If we can't explain important business functionality in a Cucumber, and we can't tie that Cucumber Gherkin code to automatically run regression tests for those features, then the organization hasn't done its job.  Cucumber forces us to "think it through".

That being said, it has been tempting to "short-circuit" Cucumber and, too often, not use it fully (or not at all).  In such circumstances, it has cost us:

1. A couple of developers have accumulated very high "bus numbers".  They have way too much of the business logic in their heads, and increasingly they can't even remember what's current.  
2. New developers are slowed down by not having the information in a reliably-maintained set of external requirements.
3. Product managers have a difficult time communicating when a cuke-precise document isn't available to collaborate around.
4. As a result, much time is spent
1. Trying to determine requirements.
2. Debugging at the system level rather than at the unit level.
3. Figuring out what code should be removed.
4. Tracking down and correcting bad data.
5. and as a result, it has become increasingly difficult to accurately project sprint velocity in areas where we haven't been 'cuke-diligent'.
   

So our struggle is to use Cucumber to flesh out business requirements and to attach those to automated regression tests.  When we use it, life is good.  When we don't, well...

All essential points whose importance cannot be overstated.

The Point about Cucumber is that it forces an upfront discussion about what needs to be done and why it needs to be done and then provides a rigorous means of following through on the descisions made from those discussions.  In my experience too much time is wasted revisiting old issues because the exact meaning of what was previously decided is either confused or forgotten. Or, worse, simply fundamentally misunderstood by the participants each of whom goes away with their own idea of what was meant by what was said and only realize this after considerable efforts have been wasted.

Cucumber is different. As has been said it is not testing albeit testing is, in my opinion, an essential element in getting the real value out of Cucumber.  it is a way of constructing a shared view of the world that can be objectively demonstrated through reproducible outcomes using known quantities.  In short it is a science that requires discipline and not an art that requires brilliance.

The complaints about Cucumber seem to me to really amount to the same beliefs used to justify self-documenting code.  An unwillingness to face the amount of real drudge-work it takes to build things to last.
 

[Anthony Green]

You could ask Steve to consider changing the tone of the summary: 

http://www.manning-sandbox.com/thread.jspa?messageID=131535&#131535 

[Kosmas]

It seems that you already did Anthony :-), Thanks

[Jeff Nyman]

On Saturday, September 21, 2013 2:13:31 PM UTC-5, Aslak Hellesøy wrote:

The gist of it is that contrary to popular belief, Cucumber was never meant to be a testing tool,

but a communication/collaboration tool.

Well, to be fair, the Cucumber Book has sentences like this:

"What makes Cucumber stand out from the crowd of other testing tools is that

it has been designed specifically to ensure the acceptance tests can easily be

read—and written—by anyone on the team."

When people see "stand out from the crowd of OTHER testing tools," it clearly lumps Cucumber into that category.

Here's another line from the book (in section 4.5):

"Cucumber is a testing tool, and it’s in the Ruby code of a step definition where

our tests find out whether a step has succeeded in whatever it set out to do."

So, it's not all that hard to see why people might think Cucumber is thought of as a testing tool when the very book used to promote it says exactly that.

- Jeff

[aslak hellesoy]

On Sat, Sep 28, 2013 at 11:44 AM, Jeff Nyman <jeff...@gmail.com> wrote:

On Saturday, September 21, 2013 2:13:31 PM UTC-5, Aslak Hellesøy wrote:

The gist of it is that contrary to popular belief, Cucumber was never meant to be a testing tool,

but a communication/collaboration tool.

Well, to be fair, the Cucumber Book has sentences like this:

"What makes Cucumber stand out from the crowd of other testing tools is that

it has been designed specifically to ensure the acceptance tests can easily be

read—and written—by anyone on the team."

When people see "stand out from the crowd of OTHER testing tools," it clearly lumps Cucumber into that category.

When I said that "Cucumber was not meant to be a testing tool" that was a simplification to make an important point: Testing is not its primary purpose.

Cucumber is a tool with multiple facets:

1) Collaboration between BAs, testers and programmers

2) Outside-In development

3) Automated testing

You can consider this a ranking of both importance and chronological order in what I'm going to start calling "The Cucumber Workflow":

Collaboratively write a few new Scenarios, involving all stakeholders on the team - technical and non-technical. This builds a shared understanding

of what needs to be built, and gives concrete examples of how the software is intended to behave. There is no testing yet, only conversation.

Starting from these new Scenarios, programmers use feedback from those scenarios (executed by Cucumber) to guide them to what to write next. This is usually some kind of user interface. There is no testing yet, only programming and emergent architecture design. This is what we refer to as "Outside-In".

As outer parts of the system materialise a little more, Scenarios will still not pass, and programmers drop down a level in the implementation onion - business logic, persistence, networking and so on. This is where we often recommend taking a break from Cucumber and drop down to classic TDD, using xUnit tools like JUnit or RSpec. There is no testing yet - there is nothing finished to test. We're still just programming and making our system crystallise a little more.

Finally, when a Scenario is green we have a little piece of working software. And the leftover is a few regression tests: The Scenarios we wrote in Step 1.

This cycle is repeated many times, as frequently as possible. The time scale is hours and days, not weeks and months.

This is what we have tried to communicate in the Cucumber Book in the early chapters. Perhaps we need to communicate it more clearly in the online documentation as well.

The Cucumber Workflow is very different from how most other testing tools are used, because they tend to be designed for a single role of people. Programmers have xUnit tools. Traditional testers have tools like HP Quality Center. Neither of them encourage much cross-discipline collaboration.

Traditional testers almost invariably write tests after the software is written. They tend to be very prescriptive click-type-verify imperative tests. Using Cucumber for this is certainly possible, and many people do (unfortunately). Because of Cucumber's nature of being embedded into the software build, programmers are now exposed to them as well, and this is where the disconnect starts. Such tests are very different from the kind of tests programmers tend to write, especially if they were written *only* by testers.

Programmers that use automated testing tools follow one of two possible workflows (or sometimes a mix of both): TDD writing tests after the code is written (just like traditional QA folk, just with a different tool). Regardless of the workflow used, when these tests are only used by programmers it is hard to justify the use of Cucumber.

The Cucumber Workflow and resulting artefacts has a certain overhead. You need both plain text gherkin scenarios and step definitions in code. If cross-discipline communication is not a goal I would say it's usually not worth it.

Many teams use traditional TDD and traditional QA after the fact testing successfully. This doesn't mean you can substitute existing tools with Cucumber and expect the same success or *more* success without changing the workflow. I think a lot of people miss this point. If you start using Cucumber you have to change your workflow to succeed with it. You have to stop *testing* and start *specifying*, collaborating with others. The overhead has to be worth the increased shared understanding across disciplines.

Using Cucumber as a traditional testing tool without using it as a collaboration tool or without doing Outside In development is likely to be an unpleasant experience.

I think the main obstacle to this collaborative use of Cucumber is lack of tooling for non-technical people, and this is why we have created Cucumber Pro (https://cucumber.pro).

The other criterion for successful use of Cucumber - Outside-In - isn't something that can be solved by tooling. But perhaps it can be improved by better documentation.

Here's another line from the book (in section 4.5):

"Cucumber is a testing tool, and it’s in the Ruby code of a step definition where

our tests find out whether a step has succeeded in whatever it set out to do."

So, it's not all that hard to see why people might think Cucumber is thought of as a testing tool when the very book used to promote it says exactly that.

You have taken a couple of paragraphs out of context here. We have done our best to communicate that Cucumber is more than a testing tool. Perhaps we should have made it more clear that if you use it *only* as a testing tool you will probably be in a better place if you pick a tool that is *only* a testing tool.

Aslak

 

- Jeff

[Jeff Nyman]

On Saturday, September 28, 2013 3:33:08 PM UTC-5, Aslak Hellesøy wrote:

When I said that "Cucumber was not meant to be a testing tool" that was a simplification to make an important point: Testing is not its primary purpose.   

You have taken a couple of paragraphs out of context here. We have done our best to communicate that Cucumber is more than a testing tool. Perhaps we should have made it more clear that if you use it *only* as a testing tool you will probably be in a better place if you pick a tool that is *only* a testing tool.

What I did is quote paragraphs that people read and they certainly were not taken "out of context." Another example from the book is:

"Like most other testing tools, Cucumber uses exceptions to communicate the failure of a test."

Certainly in the book it is mentioned that Cucumber is not "just" a testing tool but also a collaboration tool. So perhaps you meant that my quotes were selective, rather than out of context. Yet in the book it is clear that Cucumber is treated, at least in part, AS a testing tool. And here's the thing: for those of us that realize testing is a design activity, and not just an execution activity, the distinction does not matter that much because testing, as a design activity, is all about collaboration. You are testing people's understanding of a shared notion of quality as it gets encoded as actionable statements that you can call acceptance tests. Calling Cucumber a testing tool is actually NOT a bad thing, as long as people have a broad view of testing and realize that testing is a multi-faceted activity. (I realize many people may not treat testing, as a concept and activity, in this way. In that case, I would rather educate on _that_ issue instead of worrying about whether something is or is not a testing tool.)

My point was simply that there can be mixed messages possible based on what people read in the Cucumber Book and this is also going to be predicated upon their view of testing. So when you say "Cucumber was never meant to be a testing tool" and a book says (direct quote) "Cucumber is a testing tool" -- you have to expect a certain amount of confusion, even if other parts of the book state that Cucumber should be used for collaboration instead of "just" testing. So even if you want to say "Cucumber should not be used solely as a testing tool", then I would prepare to also make distinctions for those in quality assurance and business analysis who know that testing is, again, both a design activity and an execution activity.

- Jeff

[aslak hellesoy]

On Sat, Sep 28, 2013 at 10:04 PM, Jeff Nyman <jeff...@gmail.com> wrote:

On Saturday, September 28, 2013 3:33:08 PM UTC-5, Aslak Hellesøy wrote:

When I said that "Cucumber was not meant to be a testing tool" that was a simplification to make an important point: Testing is not its primary purpose.   

You have taken a couple of paragraphs out of context here. We have done our best to communicate that Cucumber is more than a testing tool. Perhaps we should have made it more clear that if you use it *only* as a testing tool you will probably be in a better place if you pick a tool that is *only* a testing tool.

What I did is quote paragraphs that people read and they certainly were not taken "out of context." Another example from the book is:

"Like most other testing tools, Cucumber uses exceptions to communicate the failure of a test."

Certainly in the book it is mentioned that Cucumber is not "just" a testing tool but also a collaboration tool. So perhaps you meant that my quotes were selective, rather than out of context.

Fair enough. There is no denying that Cucumber is, among other things, a testing tool. The point I'm trying to make is that if used exclusively as a conventional testing tool, there are better alternatives.

 

Yet in the book it is clear that Cucumber is treated, at least in part, AS a testing tool. And here's the thing: for those of us that realize testing is a design activity, and not just an execution activity, the distinction does not matter that much because testing, as a design activity, is all about collaboration. You are testing people's understanding of a shared notion of quality as it gets encoded as actionable statements that you can call acceptance tests. Calling Cucumber a testing tool is actually NOT a bad thing, as long as people have a broad view of testing and realize that testing is a multi-faceted activity. (I realize many people may not treat testing, as a concept and activity, in this way. In that case, I would rather educate on _that_ issue instead of worrying about whether something is or is not a testing tool.)

Good points!

 

My point was simply that there can be mixed messages possible based on what people read in the Cucumber Book and this is also going to be predicated upon their view of testing. So when you say "Cucumber was never meant to be a testing tool" and a book says (direct quote) "Cucumber is a testing tool" -- you have to expect a certain amount of confusion, even if other parts of the book state that Cucumber should be used for collaboration instead of "just" testing.

I agree that I initially contradicted what we have said in the book. So I'll provide a more nuanced and less contradicting statement in my blog post.

 

So even if you want to say "Cucumber should not be used solely as a testing tool", then I would prepare to also make distinctions for those in quality assurance and business analysis who know that testing is, again, both a design activity and an execution activity.

I really appreciate your feedback Jeff. Getting the words right here is difficult, but also very important in order to get the point across.

[Marty Bradley]

Aslak I love the points you make here.  I've fallen into this trap when I train on BDD the group typically turns out to be just programmers and testers.  It's important to train them but I want to move to more "up front" training and get the POs involved and maybe build a Product Owner training modifying my typical User Story writing workshop  and adding in gherkin and the flow you describe about. Have you guys done training like this? - wait don't answer that I think it'll take this thread in a different direction.  Anyway, thanks for the discussion above.

--
Marty Bradley
Enterprise Agile Coach
(703) 869-2217
http://www.linkedin.com/in/martybradley
Click to scan contact information

[aslak hellesoy]

On Sat, Sep 28, 2013 at 11:00 PM, Marty Bradley <marty.ag...@gmail.com> wrote:

Aslak I love the points you make here.  I've fallen into this trap when I train on BDD the group typically turns out to be just programmers and testers.  It's important to train them but I want to move to more "up front" training and get the POs involved and maybe build a Product Owner training modifying my typical User Story writing workshop  and adding in gherkin and the flow you describe about. Have you guys done training like this? - wait don't answer that I think it'll take this thread in a different direction.

No, that's fine - I think it's on-topic.

I don't do training myself, but there are several people on this list who do. It would be interesting to hear their experience with this - training Product Owners and Business Analysts. I think it's essential in order to succeed with Executable Specifications and BDD.

Aslak

[Anthony Green]

Marty Bradley wrote:
> Have you guys done training like this? - wait don't answer that I think
> it'll take this thread in a different direction.

I think Matt Wynne could provide the kind of training you describe for
organisations that are ready for it. He and I have exchanged thoughts on
where GOOS and BDD fit into the picture on the odd occasions we've run
into one another.

[Paolo Ambrosio]

On 28 Sep 2013 21:33, "aslak hellesoy" <aslak.h...@gmail.com> wrote:
>
> On Sat, Sep 28, 2013 at 11:44 AM, Jeff Nyman <jeff...@gmail.com> wrote:
>>
>>
>> On Saturday, September 21, 2013 2:13:31 PM UTC-5, Aslak Hellesøy wrote:
>>>
>>>
>>> The gist of it is that contrary to popular belief, Cucumber was never meant to be a testing tool,
>>> but a communication/collaboration tool.
>>>
>>
>> Well, to be fair, the Cucumber Book has sentences like this:
>>
>> "What makes Cucumber stand out from the crowd of other testing tools is that
>> it has been designed specifically to ensure the acceptance tests can easily be
>> read—and written—by anyone on the team."
>>
>> When people see "stand out from the crowd of OTHER testing tools," it clearly lumps Cucumber into that category.
>>
>
> When I said that "Cucumber was not meant to be a testing tool" that was a simplification to make an important point: Testing is not its primary purpose.
>
> Cucumber is a tool with multiple facets:
>
> 1) Collaboration between BAs, testers and programmers
> 2) Outside-In development
> 3) Automated testing

In my opinion there is a fourth point (if steps are written in a declarative way):

4) Live Documentation

I know (1) and (2) are the main reasons to choose Cucumber over Fitnesse, Robot Framework, etc. but (3) and (4) are quite important as well.

[Matt Wynne]

On 28 Sep 2013, at 23:09, aslak hellesoy <aslak.h...@gmail.com> wrote:

On Sat, Sep 28, 2013 at 11:00 PM, Marty Bradley <marty.ag...@gmail.com> wrote:

Aslak I love the points you make here.  I've fallen into this trap when I train on BDD the group typically turns out to be just programmers and testers.  It's important to train them but I want to move to more "up front" training and get the POs involved and maybe build a Product Owner training modifying my typical User Story writing workshop  and adding in gherkin and the flow you describe about. Have you guys done training like this? - wait don't answer that I think it'll take this thread in a different direction.

No, that's fine - I think it's on-topic.

I don't do training myself, but there are several people on this list who do. It would be interesting to hear their experience with this - training Product Owners and Business Analysts. I think it's essential in order to succeed with Executable Specifications and BDD.

Our BDD Kickstart[1] training spends the first day with the entire team. We mandate this - I've had bad experiences in the past just doing technical training for people who want to automate tests but not spending any time helping them to change their wider workflow. So nowadays I insist we get a day with the product owners (and everyone else) in the room just working on the process of breaking down stories into scenarios collaboratively.

[1] http://kickstartacademy.io/courses/bdd-kickstart

cheers,

Matt

--

tel. +44 (0)20 8720 6842

http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com

[Marty Bradley]

That's a great idea Matt I'm going to rework some of my internal training now and then take the training public in the states.