May 7, 2019 at 14:59Introduction to Example Mapping
- Transfer
Before undertaking work on a user story, it is very important to determine acceptance criteria for yourself. This can be done when you detail the backlog or plan the next sprint. For this, some teams hold special meetings called 3 Amigo (more about them in the last article ), rallies, kick-offs according to specifications or meetings-studies.
Do not call it, for most teams this is difficult. The main difficulty is that such meetings are unstructured, and their results are incomprehensible. They are time consuming and simply boring. As a result, sessions become irregular or 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 of test cases.
Specific test cases (examples) are a great way to explore a subject area. They can be a good basis for your acceptance tests. When we discuss test cases, other aspects come up that also need to be spoken about.
Example Mapping uses a set of cards in four different colors and ballpoint pens to record new information as you speak. 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. Next, on the blue stickers indicate each of the acceptance criteria or rules that we have developed earlier. We place blue cards under yellow.
Each rule can usually be illustrated with several test cases . Each test case has its own green sticker, which is placed under the corresponding rule.
While compiling a map and discussing cases, questions may ariseto which 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 fully understood, or the time allotted for it ends.
In the process of such a conversation, a visual representation of the current understanding of history is easily and quickly built.
You may find that some rules are so obvious that they don’t need test cases. For example, if everyone understands the rule in the same way, then you do not need to waste time and torture a fixed number of test cases.
A group of several amigo should make a decent, decent story in about 25 minutes .
If you are unable 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 together at the next session by example mapping, but with answers.
Matt Wynne from Cucumber invites the meeting participants to vote in 25 minutes whether the story is ready to be submitted for development. Even if some issues remain unresolved, the team may decide that there is not much uncertainty, and it can be further developed along the way.
Example mapping helps change the scale and focus on the smallest pieces of history behavior. By compiling a map, you can select the rules, find the essence of the desired behavior, and postpone the rest for later. Because of the thoroughness of the research, example mapping acts like a filter, preventing big bold stories from getting into the sprint and then giving unpleasant surprises at the last minute. In addition, this approach saves time and helps maintain the involvement of interested people in the process.
It seems to some that 3 amigo should write acceptance tests during this meeting (for example, scripts for Cucumber). In principle, in some cases this may make sense, but more often this approach will only distract from the true purpose of the conversation.
It is clear where such an 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 towards this goal without high technology.
Therefore, instead of using the formal Gherkin scripts, just try to quickly compile a list of test cases using the naming convention.
For instance:
When uncertainty is hidden behind this case name, 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 be.
If the conversation begins to circle, then there is not enough information. Perhaps 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 about what the result should be, just write the question on the red card and move on. So the unknown will turn into a known unknown . This is a big progress.
From experience, even this aspect of mapping examples can turn 3 Amigo meetings 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 from the operation, a specialist in UX or anyone else who is involved in 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 for the role of a 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 it takes discipline to write them on stickers in a timely manner to see what is at stake.
Do not get it wrong, using Gherkin has tremendous value, especially in the early days of the project, when you develop a common language. It is vital that the scenarios are expressed so that everyone in the team believes them.
But to describe test cases in this way requires a different way of thinking. It is not only necessary to decide which cases fall into the area in question, 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 his time and energy on mapping, and leave the task of writing Gherkin to two other amigo. 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 mapping was in terms of transferring product knowledge 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 get back to work. If you try to do more, just waste your energy.
For this, we have already come up with solutions, for example, lists of stickers on Google keep or online boards with colored stickers. You can use mind-map. The main thing is that you should be able to work simply and quickly 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 yet know . There are no stupid questions, they all help to really investigate the problem.
Using this technique, you will find that the rules create natural lines of development for your story. Try to calmly relate to questions, separate them and put them aside. Then you can focus on solving the main problem. You can complicate and bring to the ideal later.
Do not call it, for most teams this is difficult. The main difficulty is that such meetings are unstructured, and their results are incomprehensible. They are time consuming and simply boring. As a result, sessions become irregular or 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 of test cases.
How it works
Specific test cases (examples) are a great way to explore a subject area. They can be a good basis for your acceptance tests. When we discuss test cases, other aspects come up that also need to be spoken about.
- Rules that generalize different cases or vice versa limit the applicability of the test case.
- Questions about scenarios when no one knows what is actually true. Or hypotheses that we put forward in order to somehow advance in the development of requirements.
- New user story that was revealed during the discussion.
Example Mapping uses a set of cards in four different colors and ballpoint pens to record new information as you speak. 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. Next, on the blue stickers indicate each of the acceptance criteria or rules that we have developed earlier. We place blue cards under yellow.
Each rule can usually be illustrated with several test cases . Each test case has its own green sticker, which is placed under the corresponding rule.
While compiling a map and discussing cases, questions may ariseto which 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 fully understood, or the time allotted for it ends.
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 much remains to be seen.
- 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 part 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 several rules that can be described in more detail separately.
You may find that some rules are so obvious that they don’t need test cases. For example, if everyone understands the rule in the same way, then you do not need to waste time and torture a fixed number of test cases.
Think for a limited time
A group of several amigo should make a decent, decent story in about 25 minutes .
If you are unable to meet the allotted time, then several options are possible:
- You are still learning to use this method (this is normal);
- your story is too big (this is definitely not good anymore);
- 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 together at the next session by example mapping, but with answers.
Matt Wynne from Cucumber invites the meeting participants to vote in 25 minutes whether the story is ready to be submitted for development. Even if some issues remain unresolved, the team may decide that there is not much uncertainty, and it can be further developed along the way.
Benefit
Example mapping helps change the scale and focus on the smallest pieces of history behavior. By compiling a map, you can select the rules, find the essence of the desired behavior, and postpone the rest for later. Because of the thoroughness of the research, example mapping acts like a filter, preventing big bold stories from getting into the sprint and then giving unpleasant surprises at the last minute. In addition, this approach saves time and helps maintain the involvement of interested people in the process.
It seems to some that 3 amigo should write acceptance tests during this meeting (for example, scripts for Cucumber). In principle, in some cases this may make sense, but more often this approach will only distract from the true purpose of the conversation.
It is clear where such an 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 towards this goal without high technology.
Simplify Recording
Therefore, instead of using the formal Gherkin scripts, just try to quickly compile a list of test cases using the naming convention.
For instance:
- where the customer has forgotten his receipt;
- where the product was purchased 15 days ago.
When uncertainty is hidden behind this case name, 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 be.
Known unknown
If the conversation begins to circle, then there is not enough information. Perhaps 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 about what the result should be, just write the question on the red card and move on. So the unknown will turn into a known unknown . This is a big progress.
From experience, even this aspect of mapping examples can turn 3 Amigo meetings 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 from the operation, a specialist in UX or anyone else who is involved in 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 for the role of a 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 it takes discipline to write them on stickers in a timely manner to see what is at stake.
So when to write on Gherkin?
Do not get it wrong, using Gherkin has tremendous value, especially in the early days of the project, when you develop a common language. It is vital that the scenarios are expressed so that everyone in the team believes them.
But to describe test cases in this way requires a different way of thinking. It is not only necessary to decide which cases fall into the area in question, 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 his time and energy on mapping, and leave the task of writing Gherkin to two other amigo. 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 mapping was in terms of transferring product knowledge 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 get back to work. If you try to do more, just waste your energy.
But I have a distributed team!
For this, we have already come up with solutions, for example, lists of stickers on Google keep or online boards with colored stickers. You can use mind-map. The main thing is that you should be able to work simply and quickly 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 yet know . There are no stupid questions, they all help to really investigate the problem.
Using this technique, you will find that the rules create natural lines of development for your story. Try to calmly relate to questions, separate them and put them aside. Then you can focus on solving the main problem. You can complicate and bring to the ideal later.
We will talk about the practice of 3 Amigo to work out the requirements and build test case cards at the QualityConf conference . In addition, the list of accepted reports contains other extremely interesting practical approaches for creating a high-quality IT product. The QualityConf conference will be held for the first time as part of the RIT ++ festival on May 27 and 28, have time to join.