Gherkin Tips & Tricks

A few months ago, I was selected to give a presentation at the Testnet ‘voorjaarsevenement’. My talk was about Gherkin and how to improve your Feature files and step definitions.  It’s time to put it on the blog.

Instead of writing an introduction to Gherkin, it’s better to point you to the Cucumber wiki. They have a very good explanation of it. So let’s move on to the tips & tricks!

Feature file tips

  • Avoid long descriptions
    Features should have a short and sensible title and description. This improves readability and you do want readable and understandable Feature files, don’t you? So there should be one sentence describing the scope and content.
  • Choose a single fomat
    I don’t care if you pick “As a [role], I want [feature] so that [benefit]”  or “In order to [benefit], as a [role] I want [feature]”. However, pick one and stick with it. Again, this improves the readability. And never forget the benefit, this makes it easier to decide on the business value.
  • Features… not big portions of the application
    There should only be one Feature per file and the Feature should be reflected in the file name. If you work in larger teams, it is easier to work parallel on smaller Feature files.
  • Domain language
    Involve the customers and use their domain language. Involve them in writing the user stories or at least have them review them. Keep the language consistent accross all Features (and even projects).
  • Organization
    Organize your Features and Scenarios with the same discipline like you would organize code. You can organize them according to execution time: fast (<1/10s), slow (<1s) or glacial (>1s).  Or put them in separate subdirectories. Or tag them.

Background tips

  • Use Backgrounds
    To avoid repetitions in the feature file, Backgrounds are ideal. However, since the user has to keep the Background in mind while reading or writing the Scenarios, keep them short. Max. 4 lines.
  • Don’t include technical stuff
    The Feature file is about the user. Starting or stopping the webserver, clearing tables, etc can be implemented in the Step Definitions. it shouldn’t be mentioned in the background.
    Of course, don’t use a Background if you have only one Scenario.
  • Don’t mix
    Don’t mix backgrounds in the Feature file with @before hooks in the Step Definitions. This will drive you nuts when debugging.

Scenario tips

  • Scenario vs Scenario Outline
    In fact it is very simple: if you have only one example, use a Scenario.
    If you have more than one example, use a Scenario Outline and a table
  • Short
    Keep your scenarios short.
    Hide the implementation details.
  • Declarative steps over imperative steps
    Using declarative steps is much more concise and about WHAT the user wants to do with the system, not HOW the user wants to do it.
    Declarative example:
    Given I have logged on to the system
    Then I should see my new messages
    Imperative example:
    Give I am on the login page
    When I fill in the username
    And I fill in the password
    And I click on the ‘Submit’ button
    Then I should be logged on to the system
    And I should see my new messages

Step tips

  • AND/OR are keywords
    so don’t use them within a step
    Given I’m on the homepage and logged on
    Should be
    Given I’m on the homepage
    And I’m logged on
  • Cover happy and non-happy paths
    Testing is more than only proving it works. It’s trying to break the system.
  • Refactor
    Your library of steps will increase in time, so try to generalize your steps to increase reuse.
    You understanding of the domain will increase also, so update your language and the steps.

Tag Tips

  • Never tag the background
    Tags allow you to organize your Features and Scenarios. You can have multiple Tags per Feature or Scenario, so never tag the Background.
  • Don’t tag Scenario with same Tag as Feature
    Feature Tags are also valid for all child Scenarios, so there is no need to apply the same Tag to the Scenarios.
  • What is the benefit of Tagging a Feature
    You can Tag individual Scenarios, so think about what value would be added by Tagging an entire Feature.  There may not be much use for it. Except perhaps Tagging the Feature with the story number.
  • Tag categories
    Possible tag categories may be
    Frequency of execution: @checkin, @hourly, @daily, @nightly
    Dependencies: @local, @database, @fixtures, @proxy
    Level: @acceptance, @smoke, @sanity
    Environment: @integration, @test, @stage, @live
    Some groups also Tag according to progress: @wip, @todo, @implemented, @blocked.
    I’m not saying this is bad, if you do, make sure you keep the tags up-to-date! If you can’t do that, don’t use them.

Step Definition Tips

Most of the tips below will increase the reuse of your Step Definitions and the readability of the Feature files.

  • Use flexible pluralization
    Add a ? after the pluralized word:
    Then /^the users? should receive an email$/ do
    Now it will match both user and users
  • Use non-capturing groups
    Instead of (some text), use (?:some text). Now the result is not captures and not passed as an argument to your step definition.
    It is especially useful in combination with alternation:
    When /^(?I|they) create a profile%/
    or
    And /^once the files? (?:have|has) finished processing*/ do
  • Consolidate Step definitions
    When /^the file is (not)? present$/ do |negate|
        negate ? check_if_file_is_not_present : check_if_file_is_present
    end
  • Use unanchored regular expressions
    Normally you anchor start with ^ and end with $. Sometimes it might be useful to omit one:
    Then /^wait (\d+) seconds/ do |seconds|
        sleep(seconds.to_i)
    end
    This will allow for more flexible expressive steps:
    Then wait 2 seconds for the calculation to finish
    Then wait 5 seconds while the document is converted
    Of course this can be dangerous, so I think you can only do this for this example 😉
  • Be DRY
    Don’t Repeat Yourself.
    Refactor when necessary and reuse Step Definitions within a project across Features and perhaps even across projects.
  • Parse date/time in a natural way
    For most programming languages there are libraries that allow you to parse dates and times in a more natural way. For example in Ruby you have Chronic and in Python you can use parsedatetime or pyparsing.

So there we have it: quite a few tips to improve your Gherkin Feature files, Backgrounds and Step Definitions.

However, most important tip I can give you is to exercise discipline when writing your test automation code:

  • treat your code as production code
  • refactor when necessary
  • run your tests as often as possible
  • and don’t be too smart: somebody needs to understand next year. And that person might even be you.

For your benefit I have included my presentation and the checklists I created.

Studying for Professional Scrum Master exam

Agile and certifications, is this a good match?  Usually agile supporters are proud to not be certified.

I don’t know, but at least several founders of Scrum seem to think it is. You have 2 big Scrum certification organisations:

  • Scrum Alliance, who have the Certified Scrum certifications (Master, Product Owner, Developer, Professional, Coach and Trainer).
    ScrumAlliancePath
  • Scrum.org, who have the Professional Scrum certifications (Masters, Developers and Product Owners). Scrum.org has 2 levels for almost each type, so there is a Professional Scrum Master I and II. (PSM I, PSM II). Likewise there is a PSPO I and II.  Only Professional Scrum Developer only has one level at the moment: PSD I.

What is the difference between the 2 organisations?  Well, I’m not involved in either of them, so I only know what I found out on the internet.  Time for some gossip: Scrum Alliance started first around 2002, but by 2009 Ken Schwaber had become extreme dissatisfied in it: the organisation he helped create was more interested in and dependant on the money coming in than in the mission.  So he founded Scrum.org. A longer description of this history is available (albeit a bit hidden) on the Scrum.org website.

The certifications of the Scrum Alliance do seem to go further. Especially the Scrum Coach and Trainer are not easy.  It is not just taking an exam, but demonstrate over 1500 hours of Scrum coaching with real client references.  So if you see a Certified Scrum Coach, you know that the customers were indeed satisfied with the word delivered. These certifications however are beyond my experience at the moment, so let’s focus on the Certified Scrum Master and Professional Scrum Master.

What is the difference between these certificates? Well, again, I only took the Professional Scrum Master assessment, so I know absolutely nothing about the Certified Scrum Master certificate.  However, I do know that it is possible to take the PSM assessment without having to follow a training, while this isn’t the case for the CSM. So that was one of my reasons for taking PSM I.  That both Ken Schwaber and Jeff Sutherland are involved in Scrum.org seems to be another plus.

So, how to prepare for the assessment?

  • First step is to read the Scrum Guide. Don’t let the number of pages, 16,  fool you.  There is really a lot in it. But it is the basis for the assessment.  Everything that is assessed, is in this document! Although I must say I got a few extra questions on burndown charts for example. So do not only read it, but study it carefully. You should not only know that something is done or not, but also why, understand Scrum!
    Even though I had followed the Certified Agile Tester training (and give it also), I still found new things in it.
  • Learn more about Scrum best practices not described in the Scrum Guide. Not necessary for the assessment, but it helps to better understand why certain choices were made.
  • Try to gather some experience. More difficult since not every project is an Agile project, not every Agile project is a Scrum project and many ‘Scrum’ projects are ScrumBut projects. A ScrumBut project is of course not a good preparation for the assessment.
  • Take the Scrum Open Assessment.  These are only 30 questions (the assessment is 80 questions),  but there is a larger pool, so if you take it several times, you get a few more questions. Before you take the real assessment, you should get consistently at least 29 on the Open Assessment with time to spare. For extra insight it is useful to  take the Developer Open Assessment also several times. You need a Scrum.org account to be able to take the Open Assessments.
    I noticed several questions from the Open Assessment coming back in the real assessment.
  • Follow the suggested readings list for Scrum Master on Scrum.org. There are many good books available.  All of these can give you extra insights.

Then the assessment itself, is it difficult?

Not so much, I scored 95%. If you know Scrum and understand it, achieving the required 85% should be quite easy to do. I needed 25 minutes to go through all 80 questions. So that left me plenty of time to go back to the bookmarked questions.  Some needed indeed some adjustment, but in the end I could finish easily in time.

So, does this prove I am now a good Scrum Master?

Of course not, no multiple choice exam can prove that. Just like ISTQB Foundation doesn’t prove that you are a good tester.  It only proves that you know the terminology, some techniques, have an understanding of risks, etc.  Prove that you are a good tester? That can only be done on the job.

Likewise, this certificate does prove that I know Scrum. And perhaps also that I can apply it. Doing this on a real project, with real people/organizational/time issues and constraints, that’s the next challenge!