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.

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.