A mental model is a person’s understanding of how something works, that aids in making faster and better decisions. We all rely on it to understand the complex world around us 💡 In this article, we will discuss a particular mental model called “The map is not the territory” and how it can guide your decisions as a tester.
“The map is not the territory” was originally a quote from Alfred Korzybski to convey the fact that we often confuse models of reality with reality itself. We use them to simplify the complexity of things that are around us.
“Our perception (map) is not the reality (territory)”
Just like all models, maps are an abstraction and reduction of the real world 🌎 Maps are a rough representation of reality but not the reality itself. Hence even the best maps are imperfect. We often fail to understand this limitation.
Use requirement documents just as a guide
Agile’s incremental approach enables teams to validate if the increment (territory) matches the owner’s expectations and perception of the software (map). Today Scrum is the preferred choice for every organization to build and ship software.
I have seen several teams and organizations who claim to be Agile by conducting a couple of Scrum ceremonies like standups and retrospectives, without understanding the intent behind them.
When teams fail to understand the fundamentals of Agile they miss out on opportunities to inspect and adapt. Let’s look at an example of how mistaking the map for the territory can lead to problems:
A team was working on a complete revamp of the user interface. The aim of the revamp was to improve the user experience. Tyler (the tester) was in charge of testing this software UI upgrade.
The complete look and feel of the application were improved to great extent ✅ The application had a drag and drop image uploader that let the user upload the desired images.
The image uploader seem to function fine, however, the area to drag and drop the image was too narrow. A left-aligned narrow area would lead to errors as it requires a more precise interaction.
Tyler spoke to Dave (the developer) and discussed his concern. Tyler expressed that drag and drop interfaces need to be wide enough so that users get ample area to drag and drop images.
Dave said that the requirement document did not specify the width of the drag and drop editor. He tried to justify that it was not an issue 🤷♂️ Dave seemed to forget that the objective of the revamp was to improve the user experience and more importantly “Map is not the territory”.
Requirement documentation is a map that attempts to describe the customer’s needs for the product, but it does not inherently deliver business value. Requirement documentation is a description of the product and not the product itself. A good tester understands that just like a map, a requirement document has the following limitations:
- Requirement documents can be inaccurate and incorrect.
- They can miss certain information.
- Implicit requirements – things that users will expect but might not be explicitly captured in the requirement document.
- They can be interpreted differently by people, which may lead to mistakes.
- A requirement document may also go outdated and does not reflect the updated information.
All models are wrong but some are useful
The useful models we use like an architecture diagram, state transition diagram, or a use case diagram do not represent the exact real behavior in reality. For instance, an architectural diagram is an abstraction of the overall outline of the software system, and illustrates how different components in a software system interact with one another.
The architectural diagram helps us understand complex systems and their interactions. However, it’s a simplification, hence does not capture everything given the number of moving parts, and does not perfectly reflect how the real software will operate.
Test plans are helpful, however they are not perfect either. They can be flawed due to uncertainty and unknowns. Things can change quickly in an Agile environment. In reality, we may deviate from our original test plan. You need to constantly monitor and update your test plan to make the necessary adjustments and keep your project on track 💪
Even data can be misleading
Successful organizations gather and analyze data to make informed decisions 📊 Data does not lie but it may not tell the whole truth. We have the tendency to find non-existent patterns by making flawed correlations.
For example, a team felt that there is a correlation between the releases and production issues. They felt that more releases lead to more issues. The data they analyzed also hinted the same thing. They decided to slow down on the number of releases they made. However, the production issues did not reduce despite lesser releases.
Later, upon detailed investigation, the team realized that customers mostly reported legacy issues that had nothing to do with the new releases. Our psychology is the culprit of why we see non-existent patterns. Confirmation bias tricks you search for the data that confirms your beliefs. Hence analyze metrics, numbers, and trends from different angles.
- The same data can be interpreted/perceived in different ways by different people.
- The same data can be visualized differently and everyone may give you a different kind of insight.
- A small portion of data (sampling) may not represent the entirety and can be misleading.
- Every data visualization focuses on a particular aspect and also leaves out some information.
- Without the context data is meaningless.
“Everything simple is false. Everything complex is unusable” – Paul Valéry
Simple models are less accurate but are easier to understand. As the model continues to be more complete and accurate they become less understandable. Accept this imperfection and act accordingly. As a tester, be skeptical about maps and understand their limitations.
No matter how accurate a model seems, remind yourself that it is an imperfect explanation of reality. Knowing this helps you to think through problems and make better decisions 💫