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 [1]. 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 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 understand.

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 handled correctly.

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 your game.

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 different contexts.

References

[1] Systematic Inventive Thinking

http://en.wikipedia.org/wiki/Systematic_inventive_thinking