Systematic Inventive Thinking and Game Testing
This article will explore how you can use the Systematic Inventive Thinking
Method to generate tests with user behavior as a starting point.
How can you as a game tester continuously stay one step ahead of all potential
problems? How can you think about improvements that would positively impact
the user when you run your tests? It requires creativity to think about all
possible scenarios different user types can come up with, and all needs and
preferences of these users. Game testers have a unique possibility to give this
type of input to game designers and developers early in the development
process, since they have likely spent more time playing the game than anyone
else at that stage.
Some might think of creativity as a field solely for artists and designers, but this
is something each and every one of us should develop, and it should be used for a
wide variety of tasks. The alternative is stagnation.
The question that remains is “How?”. How can I be creative? Maybe I feel like I
am not a creative person. I don’t randomly come up with awesome new ideas. I
have a hard time thinking outside the box, coming up with unique new use cases
and scenarios. I don’t come up with interesting solutions to the problems that
users will face, which I see every day during my testing.
Creativity is not some magical, mysterious process reserved for designers and
artists. There are methods to make the creative process more concrete. One of
these methods, which I prefer because it is quite simple, is Systematic Inventive
Thinking . By making the creative process more methodical and systematic,
and by making it relatively simple, everyone can participate. And this is what all
companies need, regardless of field. To harness to innovative capabilities of all of
their employees – not only the top 10%. When everyone is participating we are
all triggering each other to become more innovative and creative, everyone
adding their unique view to the common creative pool. It is in collaboration and
discussion that most great ideas are born.
So what is Systematic Inventive Thinking (SIT)? SIT is a thinking tool developed
for generating new ideas, and solving problems. Studies show that the main
difficulty faced by problem solvers is not coming up with a large quantity of
ideas, but coming up with original ideas. SIT, a structured approach to idea
generation, instead of just brainstorming, was created to solve this difficulty.
SIT has two major components that can be good to focus on as an introduction:
The Closed World Principle
Five Thinking Tools
The closed world principle focuses on “thinking inside the box”. Thinking outside
the box requires stepping outside of your normal thinking pattern, and this is
very difficult, since it is after all outside our normal thinking pattern. Thinking
inside the box requires us to find a creative solution by heavily limiting the space
of possibilities. This means that when coming up with new ideas for
improvements or for solving problems you are only allowed to use elements
already existing in the game/problem/behavior, or in the immediate
environment. This condition forces us to rely on resources already at our
disposal, rather than using new external resources for the solution. By limiting
our thinking space we have to take a closer look at the elements already
available and their dependencies, forcing us to question what we have taken for
granted, allowing us to come up with innovative and simple ideas.
The five thinking tools make this principle more practical and easier to
4. Task Unification
5. Attribute Dependency
So what are these tools, and how can they be applied to game testing? We often
have some conceived notion of what a normal user is and the use pattern of that
person. And we probably have tests covering this use pattern. By applying the
five thinking tools on that pattern we can come up with interesting new test
cases, and perhaps also ideas for how to improve game play for users who differ
from the norm. This diverges somewhat form how Systematic Inventive Thinking
is normally used – usually you have a product, process or strategy, now we are
looking at user behavior.
We start by subtracting something important from that behavior. The ability to
see colors. Suddenly you have interesting new use cases, and also perhaps some
ideas for a feature that makes the game playable for the colorblind. Let us
subtract something else. The ability to charge the laptop, tablet or mobile device.
Suddenly you have a lot of new use cases related to resource consumption by the
game. The ability to update the gaming device OS. Now you have several
compatibility tests you need to run.
Now we instead apply multiplication to the normal user pattern. What if the user
always presses multiple times instead of once when pressing different buttons?
What if the user presses many buttons at the same time instead of just one? For
this you can add different types of stress tests to secure that multiple presses is
Division is slightly harder than the two first tools. Try breaking up a certain
behavior into components and try to reconstruct the behavior in different ways.
Maybe instead of connecting your game to social media then start playing; you
start playing and the want to connect your game to media during play.
Task unification assigns a new or additional task to an existing resource. How
does this apply to our user behavior and what tests can we create using this tool?
What if the user is playing the game on a mobile device (task A) and suddenly
also starts walking (task B), perhaps dropping Wi-Fi connection from time to
time, while receiving text messages from a friend (task C)? Your existing
resource (the user) is suddenly involved in a lot of tasks, both in and outside
The final tool is attribute dependency. Creating and dissolving dependencies
between variables of a product. What does this mean for us and our user
behavior? What variables does a behavior have? Intensity, length, frequency are
some examples. What if you suddenly do something that you usually do for a
long time, with low frequency, and low intensity, but instead to it for a short
time, often and with high intensity? Maybe the user previously looked at the
game world map once every hour, studied it for a long time, and didn’t click
much on it, but now instead checks it every five minutes for a short period of
time, and interacts with the map a lot? This requires us to test the game world
map in a different way.
We have only looked at a single user in the examples above, but them same
methodology can be used on a group of users. How would a thousand users
normally behave? We probably have some understanding of that. Now we apply
the 5 thinking tools to this group of behaviors, and then we can probably come
up with a number of scenarios that diverge from this normal state, which we
then create tests for.
With an understanding of the closed world principle and these five thinking
tools, we can come up with new and creative tests for different types of user
behavior. We started with a normal user behavior and then came up with a host
of similar but diverging behaviors which we then created tests for. The more we
use this method, the better we become at systematically coming up with creative
ideas, which is valuable in every part of game development.
Of course mastering this method requires a lot of practice, and is most likely a
lifelong journey, but even for a novice like myself, it has been very valuable in
The Five Thinking Tools How it applies to creating tests
Subtraction Apply different constraints to user
Multiplication Multiply user behavior
Division Rearrange user behavior in time &
Task Unification Add additional tasks to a behavior
Attribute Dependency Change dependencies in variables of