Hi Naresh!

What are the 12 most important issues?  To be frank with you, I don't want to commit the exact list at this time, as I may decide to change it as I continue to work with teams on this, but as of now, here is my "Baker's Dozen" (threw an extra one in for no extra charge).

1. Communicative - more than just using given, when, and then against an unstructured narrative
2. Create a Domain Specific Language - the precise vocabulary that gives us unambiguous business context (and build your domain model side by side with this DSL)
3. Declarative, not Imperative - describe what, not how (as that may change over time, especially in user interfaces) (also, think of how SQL joins speak to what to do, not how it is accomplished)
4. Write repeatable tests - never assume any particular backend state (always establish a backend state to start from)
5. Use loads of tags - enable quick testing (perhaps using test doubled dependencies), thorough testing (perhaps nightly), complete regression testing (perhaps every browser, device type, OS version, etc), specific feature sets, etc.
6. Make sure that you can use the same test suite on every environment easily (perhaps with property files)
7. Selenium testing can be really tough (especially when asynchronous HTTP is going on), but it is vital to make things work reliably (and never ever use Thread.Sleep - master "wait.until ExpectedConditions” concepts)
8. Refactor your tests along with your code, both as the DSL changes as well as the solution changes - it should be easy for someone to read the tests and understand what is being asked for from the Gherkin (and the DSL will give hints as to the “why” this “what” is different from the others)
9. Feature files should start with a happy path and then go into each and every alternative and exception - that’s the TDD/BDD way!
10. Organize your feature files in the same repository and taxonomy as the code it supports - BDD is not purely a testing activity, but part of the way that we develop code!
11. Never allow the sun to set on a failing test case - this is no different than doing TDD - the build is broken by a failing test just as much as if some of the code did not compile
12. Remember that the the Cucumber tests that you put together are living documentation.  They should aid people understand what the code does and allow you to quickly verify that the code is ready to ship after a build.  If you are driving Selenium behind your Cucumber tests, and take screenshots at each screen transition, you should be able to put together a “flip movie” that is almost a screencast, and shows a use case from start to finish.  Those are great, not just for training, but for automated “user acceptance” testing, as well.
13. Make absolutely sure that you use and trust the Three Amigos to define and develop your BDD suite (business person for the whats and whys, developer to make suggest and validate the development abstractions, and tester to make sure that nothing is forgotten about)

Anyhow, that's pretty much what I want to get through.

I see many, many teams trying to drive Selenium tests through Cucumber.  While that's great, many of them are doing this as a "QA" activity.  I'll put up with that, but I want to make sure that the people writing those tests adhere to the software craftsmanship that the rest of the Delivery Team developers should be laboring under.

I was planning on introducing each area and show examples to support a bad versus good approach.  This might work much better as a 90 minute hands-on session.  But I'm not planning on teaching everything about Cucumber in 90 minutes.  In other words, as a workshop, I would expect that people have already done the cucumber.org calculator.

Sorry that I don't have slides or videos from a past presentation of this.  Agile India 2015 would have an exclusive!  For at least a while...  :-)

Hi Joel!

This session is definately not one that tries to extoll the virtues of BDD or teach people who have never used Cucumber how to start.  Rather, it is one that will help people who have started using the framework, but are frustrated with problems sticking to it because of issues.  I want to help people who otherwise would say, "Cucumber looks nice, but can't work here because of A, B, C, and D".

Hope that makes sense for the conference.

--  howard