Due to COVID 19, all workshops and courses are remotely given for the foreseeable future.

Janet Gregory: Agile Consultant, Trainer, Advisor, Writer, Speaker

This post is in response to a challenge that was posted on:
How to identify the intent of a confusing scenario?

The challenge:

When faced with a confusing scenario written in Gherkin, how would you engage the other members of the team to understand the intent?

We were looking for practical tips and tricks that people in a similar situation could use to understand what’s going on, before trying to rewrite this into something more sensible.

GWT Challenge image 1

Interestingly, most of the responses tried to make the scenario better instead of trying to figure out how we might understand the scenario better.

I do see this in many of the teams I work with as well. It pays to step back sometimes and look at the problem itself instead of solving the ‘symptom’. In this case, the symptom is a poorly written scenario, so correcting the scenario and the GWT statement may not help with the basic problem.
Only one respondent – Ken Pugh, looked at it from a different perspective. His suggestion to start with understanding the domain terms is where I would likely start as well. I believe scenarios like this should be a form of documentation and when we automate them, they become living documentation and that means using domain specific language.

For example, understanding what we mean by card size, recipient, or even masked account. Are these terms the business uses? Or are they words that the development team has decided are good terms?

I would also want a visual model to represent the relationships between the terms – maybe something like this diagram. Nothing fancy but something to have a conversation about.

By making it visual, we can easily see how much we do (or don’t) understand. In this case, it left me with many questions:

  • Which relationships are 1:1 or 1 to many? Can a plan have more than one recipient?
  • Is a plan associated with the account, the user, or the recipient?
  • Does the user log into their account or into a plan?
  • Are there different kinds of users?
  • Can a user and a recipient be the same person?
  • What are all the types of card sizes? (full, reduced) and what does that really mean?

There are many more questions, but these give you an idea of what might be asked.

I would then use specific examples to make sure I understand, clearly stating assumptions.  One of the respondents said they would also use examples – a tried and true way of getting shared understanding.

Assumption: user logs into an account not a plan, although the scenario seems to indicate otherwise.

Example:  Joe (a regular user) logs into his account (he has only one account), selects Plan A (cardsize full), and sees Sally’s (Recipient) information displayed.

Name | balance | masked account | account type |
Sally    | $500      | xxxx xxxx              | B                     |

By showing an example, we can readily see what is or isn’t important, and our customers / product owner can tell us quickly what is wrong, and what assumptions might be incorrect. For example, in my world, an account has many plans, but I think that is different in this context. It looks like a plan has many accounts… but I’m not sure.

I also want to know the purpose of the scenario – what are we trying to test? The display? or the values? Or something else. It is not clear to me.

If I look at the scenario again, I might ask if setting the language is important to this scenario? Would it change the expected result at all? Ask the questions to get to the basic understanding of what we are trying to prove. Break up complex problems into smaller understandable bits. The popup is clearly an implementation detail that I don’t want to address in this scenario. What is the purpose of the popup?

One of the respondents suggested using more descriptive users within the ‘User’ column of the examples table. E.g., Admin, Customer, Supervisor (assuming the SUT allows it). Would the results change depending on the type of user?

One thing all respondents to the challenge agreed on, was that scenario was too big and should be broken down.

If a new team member coming into your system cannot understand the behavior of the system based on a scenario, it might be a good indication that it needs a bit of rework. To have living documentation, it needs to be business readable. If you don’t know what a test is testing, it likely shouldn’t be automated.


5 comments on “GWT Challenge #22

    • Sorry Matt, I do not. This example was meant to show how a well-meaning scenario could still be full of questions.

  1. The original scenario is more like a user manual for a system rather than an illustration of what business value is being provided. This is what is making much of the content irrelevant to me. Even without knowing the system, and using assumptions, I would recommend that the GWT be rewritten.

    Scenario: Provide an authenticated user information about their account in their language of choice
    Given an authenticated user
    And the user has indicated that their language is English
    And the user has logged in with valid credentials
    When the user is authenticated
    Then the system provides the user with their recipient name
    And the system provides the masked account number
    And the system provides the balance
    And the system provides the account type

    Making the scenario more concise and leaving out the navigation, for me, would clarify the business value and help me to understand what to code and test. I would not leave the navigation details out, I just wouldn’t write them in Gherkin format.

    • I agree getting rid of the navigation details is a good start. You’ve provided a scenario which seems logical, but I would still ask if the language of choice has anything to do with the actual test. You’ve also eliminated anything about the plan? Is that important? We don’t know, so we could only ask question to better understand the intent.
      However, using that scenario that you gave, I think it could be simplified further.

      Scenario: Provide an authenticated user information about their account

      Given the user has logged in with valid credentials
      When the user is authenticated
      Then the system provides the user with their recipient name, masked account number, balance, account type

  2. Totally agree with your post! As the saying goes, seek to understand, then be understood.

    A former manager shared a great piece of advice many years ago, It ges like this: if you understand it, what’s the value in rewritting it? If you don’t understand iit, you’ll just reqwite it wrong. Now, I do need to clarify that there is a differece in refactoring and rewriting. The former involves taking a working scenario and making it more readable. Rewriting involves taking a scenario that doesn’t work to one that does. This example requires a rewrite,

Leave a Reply

Your email address will not be published. Required fields are marked *