Introduction to Example Mapping
Before you start working on a user story, it is very important to determine for yourself the acceptance criteria. This can be done when you are detailing backlog or planning the next sprint. Some teams for this hold special meetings, which are called 3 Amigo (more about them in the last article ), rallies, kick-off on specifications or meeting-research.
How not to call it, for most teams it is difficult. The main difficulty is that such meetings are unstructured, and their result is incomprehensible. They take a lot of time and just boring. As a result, sessions become irregular or are completely abandoned.
But there is an easy way to make such meetings short and very productive. And this method is called Example Mapping or Mapping Test Cases.
')
Specific test cases (examples) are a great way to explore the subject area. They can be a good basis for your acceptance tests. When we discuss test cases, other aspects emerge that also need to be pronounced.
In Example Mapping, a set of cards of four different colors and pens are used to record new information in the course of a conversation. During the meeting, information is recorded on the cards and placed on the board, as in the picture above.
First, on the yellow sticker you need to write down the story itself and place it on the top of the board. Further, on the blue stickers we indicate each of the acceptance criteria or rules that we have developed earlier. Blue cards are placed under the yellow.
Each rule can usually be illustrated with several test cases . For each test case has its own green sticker that fits under the appropriate rule.
While we are making a map and discussing cases, there may be questions that none of those present can answer. We fix them on red stickers and continue the discussion.
The meeting continues until everyone is convinced that the story is completely clear, or the time allocated for it will end.
In the process of such a conversation, a visual representation of the current understanding of history is easily and quickly built.
It may be found that some rules are so obvious that they do not need test cases. For example, if everyone understands the rule in the same way, then there is no need to waste time and extort a fixed number of test cases.
A group of several amigo should make a clear story of decent size in about 25 minutes .
If you fail to meet the allotted time, then several options are possible:
What can be done? Either try to divide the story into several, or give the owner of the product homework, so that later you will return to this story in the next session on example mapping, but with the answers.
Matt Wynne from Cucumber invites meeting participants to vote in 25 minutes if the story is ready for transfer to the development. Even if some issues remain unresolved, the team may decide that there is not much uncertainty, and it can be finalized along the way.
Example mapping helps to change the scale and focus on the smallest fragments of history behavior. Making a map, you can select the rules, find the essence of the desired behavior, and the rest is put off until later. Because of such thoroughness of the study, the example mapping acts as a filter, preventing big fat stories from getting into the sprint, then giving unpleasant surprises at the last minute. In addition, this approach saves time and helps to keep interested people involved in the process.
Some people think that 3 amigos must write acceptance tests during this meeting (for example, scripts for Cucumber). In principle, in some cases this may make sense, but more often such an approach will only distract from the true purpose of the conversation.
It is clear where this opinion comes from: the obvious goal is to take a user story, which already has some predefined acceptance criteria, and find test cases that can be turned into acceptance tests.
The real goal is to achieve a common understanding of what is needed to create a story. You can quickly move to this goal without high technology.
So instead of using formal Gherkin scripts, just try to quickly assemble a list of test cases using a naming convention.
For example:
When behind the title of the case there is uncertainty, you instinctively want specifics and details. But even then it is not necessary to adhere to the rigid structure Given When Then.
If the result (“then”) is unclear, the example will not work, but the question will turn out.
If the conversation begins to go in a circle, then there is not enough information. Maybe the meeting does not have the right person, or you need to do some research or use Spike .
Instead of listening to each participant's opinion on how, from their point of view, the result should be, just write down the question on the red card and move on. So the unknown will turn into the known unknown . This is a big progress.
From experience, even this aspect of mapping examples can turn meetings of 3 Amigos from boring to fast and productive.
The minimum is your 3 amigo: developer, tester and product owner (business analyst). This is just a minimum. In addition, you can invite someone out of service, a specialist in UX, or anyone else who is related to the story under discussion. Anyone who can help find new questions or turn questions into answers during a conversation will be helpful.
While you are mastering this technique, it is convenient to find someone to play the role of facilitator. His formal task will be to ensure that everything said is immediately recorded on stickers. Test cases and questions are quickly discussed during the session, and discipline is required in order to record them on stickers in a timely manner to see what is being said.
Don't misunderstand, there is tremendous value in using Gherkin, especially in the early days of the project, when you develop a common language. It is vital that the scripts be expressed so that everyone on the team believes them.
But to describe test cases in this way requires a different way of thinking. It is necessary not only to decide which cases fall into the area under consideration, and establish general rules for them.
For a team that works with a fairly mature domain language, it is more profitable for the product owner to spend their time and energy on mapping, and leave the task of writing Gherkin to the other two amigos. After they develop the Gherkin specification, the product owner will be able to give feedback. By asking yourself the question: “Would I write like that?” You can check how effective the preparation of the map was in terms of transferring knowledge about the product to your amigo.
In practice, it is recommended to meet every other day . Just select one user story and give it 25 minutes of attention, and then return to work. If you try to do more, just waste your energy.
To do this, they have already come up with solutions, for example, lists of stickers in Google keep or online boards with colored stickers. You can use mind-map. The main thing is that you should be quick and easy to work so that you can focus on the conversation .
It is important to clearly distinguish between rules and test cases before using example mapping. There is a fun exercise for this.
Remember, the ultimate goal of such a meeting is to discover what you do not know yet . There are no stupid questions, they all help to truly explore the problem.
Working on this technique, you will find that the rules create the natural lines of development of your story. Try to calmly refer to the questions, separate them and set aside. Then you can focus on solving the main problem. Complicate and bring to the ideal can be later.
How not to call it, for most teams it is difficult. The main difficulty is that such meetings are unstructured, and their result is incomprehensible. They take a lot of time and just boring. As a result, sessions become irregular or are completely abandoned.
But there is an easy way to make such meetings short and very productive. And this method is called Example Mapping or Mapping Test Cases.
')
How it works
Specific test cases (examples) are a great way to explore the subject area. They can be a good basis for your acceptance tests. When we discuss test cases, other aspects emerge that also need to be pronounced.
- Rules that summarize different cases or, on the contrary, limit the areas of applicability of the test case.
- Questions about scenarios where no one knows what is actually true. Or hypotheses that we put forward in order to somehow advance in the elaboration of requirements.
- New user stories that came to light during the discussion.
In Example Mapping, a set of cards of four different colors and pens are used to record new information in the course of a conversation. During the meeting, information is recorded on the cards and placed on the board, as in the picture above.
First, on the yellow sticker you need to write down the story itself and place it on the top of the board. Further, on the blue stickers we indicate each of the acceptance criteria or rules that we have developed earlier. Blue cards are placed under the yellow.
Each rule can usually be illustrated with several test cases . For each test case has its own green sticker that fits under the appropriate rule.
While we are making a map and discussing cases, there may be questions that none of those present can answer. We fix them on red stickers and continue the discussion.
The meeting continues until everyone is convinced that the story is completely clear, or the time allocated for it will end.
Instant feedback
In the process of such a conversation, a visual representation of the current understanding of history is easily and quickly built.
- A board covered with red stickers (questions) says that there is still much to be clarified.
- A board covered with blue stickers (rules) indicates that the story is large and complex. Perhaps you need to decompose it. Maybe you need to take another yellow sticker (stories) and put some of the stories in the backlog.
- If the rule has too many test cases, then perhaps it is too complicated, and you need to highlight a few rules that can be described in more detail separately.
It may be found that some rules are so obvious that they do not need test cases. For example, if everyone understands the rule in the same way, then there is no need to waste time and extort a fixed number of test cases.
Thinking for a limited time
A group of several amigo should make a clear story of decent size in about 25 minutes .
If you fail to meet the allotted time, then several options are possible:
- you are still learning to use this method (this is normal);
- you have too much history (this is definitely not good);
- There is too much uncertainty in your story.
What can be done? Either try to divide the story into several, or give the owner of the product homework, so that later you will return to this story in the next session on example mapping, but with the answers.
Matt Wynne from Cucumber invites meeting participants to vote in 25 minutes if the story is ready for transfer to the development. Even if some issues remain unresolved, the team may decide that there is not much uncertainty, and it can be finalized along the way.
Benefit
Example mapping helps to change the scale and focus on the smallest fragments of history behavior. Making a map, you can select the rules, find the essence of the desired behavior, and the rest is put off until later. Because of such thoroughness of the study, the example mapping acts as a filter, preventing big fat stories from getting into the sprint, then giving unpleasant surprises at the last minute. In addition, this approach saves time and helps to keep interested people involved in the process.
Some people think that 3 amigos must write acceptance tests during this meeting (for example, scripts for Cucumber). In principle, in some cases this may make sense, but more often such an approach will only distract from the true purpose of the conversation.
It is clear where this opinion comes from: the obvious goal is to take a user story, which already has some predefined acceptance criteria, and find test cases that can be turned into acceptance tests.
The real goal is to achieve a common understanding of what is needed to create a story. You can quickly move to this goal without high technology.
Simplify recording
So instead of using formal Gherkin scripts, just try to quickly assemble a list of test cases using a naming convention.
For example:
- where the customer has forgotten his receipt;
- where the product was purchased 15 days ago.
When behind the title of the case there is uncertainty, you instinctively want specifics and details. But even then it is not necessary to adhere to the rigid structure Given When Then.
If the result (“then”) is unclear, the example will not work, but the question will turn out.
Known unknowns
If the conversation begins to go in a circle, then there is not enough information. Maybe the meeting does not have the right person, or you need to do some research or use Spike .
Instead of listening to each participant's opinion on how, from their point of view, the result should be, just write down the question on the red card and move on. So the unknown will turn into the known unknown . This is a big progress.
From experience, even this aspect of mapping examples can turn meetings of 3 Amigos from boring to fast and productive.
Who should participate?
The minimum is your 3 amigo: developer, tester and product owner (business analyst). This is just a minimum. In addition, you can invite someone out of service, a specialist in UX, or anyone else who is related to the story under discussion. Anyone who can help find new questions or turn questions into answers during a conversation will be helpful.
While you are mastering this technique, it is convenient to find someone to play the role of facilitator. His formal task will be to ensure that everything said is immediately recorded on stickers. Test cases and questions are quickly discussed during the session, and discipline is required in order to record them on stickers in a timely manner to see what is being said.
So, when to write on Gherkin?
Don't misunderstand, there is tremendous value in using Gherkin, especially in the early days of the project, when you develop a common language. It is vital that the scripts be expressed so that everyone on the team believes them.
But to describe test cases in this way requires a different way of thinking. It is necessary not only to decide which cases fall into the area under consideration, and establish general rules for them.
For a team that works with a fairly mature domain language, it is more profitable for the product owner to spend their time and energy on mapping, and leave the task of writing Gherkin to the other two amigos. After they develop the Gherkin specification, the product owner will be able to give feedback. By asking yourself the question: “Would I write like that?” You can check how effective the preparation of the map was in terms of transferring knowledge about the product to your amigo.
How often do this?
In practice, it is recommended to meet every other day . Just select one user story and give it 25 minutes of attention, and then return to work. If you try to do more, just waste your energy.
But I have a distributed team!
To do this, they have already come up with solutions, for example, lists of stickers in Google keep or online boards with colored stickers. You can use mind-map. The main thing is that you should be quick and easy to work so that you can focus on the conversation .
A few final tips
It is important to clearly distinguish between rules and test cases before using example mapping. There is a fun exercise for this.
Remember, the ultimate goal of such a meeting is to discover what you do not know yet . There are no stupid questions, they all help to truly explore the problem.
Working on this technique, you will find that the rules create the natural lines of development of your story. Try to calmly refer to the questions, separate them and set aside. Then you can focus on solving the main problem. Complicate and bring to the ideal can be later.
We will talk about the practice of 3 Amigo to study the requirements and build test case maps at the QualityConf conference. In addition, in the list of accepted reports there are other very interesting practical approaches for creating a high-quality IT product. The QualityConf conference will be held for the first time during the RIT ++ festival on May 27 and 28, manage to join.
Source: https://habr.com/ru/post/450844/
All Articles