Getting Past the 50+70=120 Calculator in Cucumber: 12 Things to Work On

agile-lifecycle Talk 45 Mins Intermediate bdd executable-requirements automated-regression-testing agile-practices
Howard Deiner
Howard Deiner
Agile Process and Technical Practices Coach
SolutionsIQ

With the best of intentions, people have flocked to Behavior Driven Development by way of Cucumber over the past few years, and that’s a great thing!  But just like dieting, where great things can fall to the wayside from the temptation to indulge in wonderful desserts, BDD can fall to the wayside due to pressure to deliver more and more functionality Sprint over Sprint.  Many times, Cucumber becomes just a way to automate a bunch of tests, which isn’t bad by itself, even if it doesn’t get to the core of how Product Owners and the Delivery Team should start to communicate.  But without constant attention, that great garden of creeping Cucumber vines becomes a tangled mess that slowly withers away under massive technical debt.

Howard will guide you through 12 of the most important issues to work on in your garden of executable requirements.  We’ll discuss and explore topics ranging from the easy to comprehend (such as imperative versus declarative style) to the difficult to deliver (such as how to keep Gherkin driven Selenium WebDriver tests working dependably through the use of advanced ExpectedCondition techniques).  By the end of the session, you should have plenty to indulge in on a healthy diet of BDD!

 
1 favorite thumb_down thumb_up 7 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Talk

This session will discuss 12 common issues that people can improve on when developing with Cucumber, with special emphasis on techniques to employ when attempting to use Selenium WebDriver.  The emphasis will be on craftsmanship and keeping technical debt low, so the automation suites can grow with the least amount of drag.

After the discussion of the 12 items, there will be a live demo of about 4 of the items, so people can actually experience what was talked through.  I want to leave people with enough momentum of "getting it" that they will immediatly apply the patterns of goodness to their own work!

Learning Outcome

A much better understanding on how to employ "The 3 Amigos" to define executable requirements and iteratively implement both the code and the automated tests that support it.

Target Audience

Members of "The 3 Amigos", Software Developers, QA Testers

schedule Submitted 4 years ago

Public Feedback

comment Suggest improvements to the Speaker
  • Naresh Jain
    By Naresh Jain  ~  4 years ago
    reply Reply

    Hi Howard,

    What are the 12 most important issues to work on with regards to executable requirements?

    Also would you conisder doing a hands-on session instead of a 45 mins talk?

    Slides and Videos from past presentation will help the selection committee.

    • Howard Deiner
      By Howard Deiner  ~  4 years ago
      reply Reply

      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...  :-)

      • Joel Tosi
        By Joel Tosi  ~  4 years ago
        reply Reply

        Hi Howard,

            We think it might be most interesting / valuable to the attendees if we tweaked the session a tad - please let us know your thoughts.

        What if you presented the 12 items as a quick overview and then demo'ed your top 4?  Would that be something you would be comfortable with?  That way attendees get the interest of the 12 and can concretely see 4 and get a little depth in them.

         

        Please let us know your thoughts

        Best,

        Joel

        • Howard Deiner
          By Howard Deiner  ~  4 years ago
          reply Reply

          That's an excellent idea, Joel!  I'll do that!!

          • Naresh Jain
            By Naresh Jain  ~  4 years ago
            reply Reply

            Thanks Howard. Can you please update the proposal to reflect the same?

  • Joel Tosi
    By Joel Tosi  ~  4 years ago
    reply Reply

    Hi Howard,

        This does feel rushed for 45 minutes, but you bring up a good point - will people that aren't familar with Cucumber be lost in this session?  I'm just trying to understand the need from the attendees.

    Best,

    Joel

    • Howard Deiner
      By Howard Deiner  ~  4 years ago
      reply Reply

      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

Active Members