Game Storming and Testing

I’m reading an excellent book at the moment called “Game Storming” by Dave Gray, Sunni Brown and James Macanufo.

 

It’s one of those books that’s given me a “lesson” or insight in every chapter.

 

In essence Game Storming is about generating new ideas and novel solutions. It’s a way of getting from Starting Point A to End Point B, where B is unknown or “Fuzzy”.

 

If the journey from A to B is quantified, mechanical, industrial, then a series of processes can be used.I guess you could call these Best Practices or Business Process. This is not what Game Storming is about. Game Storming is about exploring and journeying from A to B.

 

The authors talk about a Game World coming to fruition as:

 

• Imagine the world
• Create the world
• Open the world
• Explore the world
• Close the world

A defined and repeatable game would just be:

 

• Open the world
• Explore the world
• Close the world

I’m not doing the book justice in these brief descriptions. I’m just setting some context.

 

Every game has an opening, a game/exploration and a closing.

 

What’s this got to do with Testing?

 

Well I believe it has a lot to do with Testing, especially if you do a lot of Exploratory Testing and/or Problem Solving.

 

I urge you to read the book for it holds many insights, ideas and a much more detailed description of the elements of Game Storming.

 

The authors very kindly provide ten toolbox items to aid in designing Games. I’ve headlined the ten here, but again, the book actually offers exceptional descriptions and insights, which I’m not going to talk about here. Here’s the ten ideas with how I believe they relate to my (Exploratory) Testing.

 

1. Opening and Closing

 

In a nutshell Opening is about defining the Goals and Objectives. These should be tangible, emotionally connected to myself (i.e. in line with my motives and passions and skills) and have tangible outcomes (defects, further test ideas, information, videos, screenshots, notes).

 

The Opening part is Divergent. It’s where I list all of my ideas and thoughts about what to test. It’s about coming up with things to try, areas to explore and hypothesis about the system under test. It’s where I do a brain dump of ideas. It’s a melting pot of suggestions. Some good. Some bad. It’s the definition of the Charter.

 

Closing is the end part of the game. It’s where I pull all of my data together and define some actions, some further steps and some outcomes. It’s my Test Report at the end of the session. It’s the defects, further tests and other artefacts.

 

The Closing part is Convergent. It’s where I bring all of the information and insights together around the Goal and look at who to communicate these findings too, if necessary.

 

2. Fire Starting

Fire Starting is about igniting your mind and imagination to get those ideas flowing.

 

I typically use a Mind Map for this stage. The brain dump happens in the Mind Map. It’s a great medium for jotting ideas, diverging the ideas and linking topics together that traditionally have been kept separate.

 

I typically create a Mind Map during story kick off meetings; jotting down ideas, scenarios, questions, hunches and the different elements involved (performance, usability etc). I also use Mind Maps with an opening question to generate ideas. Something like “How many different ways are there to end a phone call?” or “How do Statistics cope when I transfer the call to multiple end points?” (I test Call Centre software).

 

3. Artefacts

These are the objects that hold information about my game (session). These include my original Mind Map of ideas, the test charters and notes, the videos I collect of the session, the defects and associated reports, the information I find and the conclusions I come to.

 

The mediums for these artefacts are not really important, but having an environment set up with all of these tools and mechanisms available instantly is essential. I don’t want to be breaking away from what I’m doing whilst I find a tool or medium to store the appropriate information.

 

The video recording is particularly useful as I branch off down new routes and ideas, feeding off the feedback that the system gives me. I have an end goal, which at times is Fuzzy, but the journey to the endpoint is important. It needs documenting.

 

4. Node Generation

The ideas that I create naturally tend to fall in to Nodes in the Mind Map. But a Node could be a container for post-it note ideas for example. A Mind Map naturally brings out the Nodes and associations, but as with all ideas generation, it could be that an idea sits under more than one Node.

 

Artefacts would also fall under the Nodes as I create further Test Ideas, Test Data and new information.

5. Meaningful Space

“It’s a way of framing any space to make the relationships within it more meaningful” A great example is given in the book about Chess. The pieces and players in a chess game are important but without the meaningful space of the board (grid) it makes no sense.

 

For me, the meaningful space when I create my Test Ideas is the Mind Map (or other medium for ideas generation). It could be a white board with stickies, or even an electronic system where each idea is deemed meaningful compared to other ideas, or customer reported defects, or business critical features etc.

 

When coming up with ideas you need to restrain your meaningful space to allow your creativity to flourish. This is especially so in bigger teams where a lack of restraint can take you miles away from your Goals. I still prefer a Mind Map for ideas generation, even in a collaborative team setting. The medium of Mind Maps seems to naturally create meaningful space.

 

Each day I view the meaningful space that is our Kanban board with our tickets and work on it. Take away the board and associated columns and it’s just a selection of stickies. The meaning comes from the columns and headers and how the stickies are located. A Test Idea on it’s own is valuable but combined in the meaningful space of a Test Lab or associated with other Test Ideas it can become ever more meaningful.

 

6. Sketching and Model Making

 

I work in pictures. I like to Visualise everything I’m brain/game storming. When I’m working with my Test Team or the Programmers I tend to draw pictures. Sometimes the drawing are very useful on their own as a piece of communication. Other times they would not work on their own as a single piece of communication, but they do aid in clearing my thinking allowing my verbal language to become clearer and more concise.

 

Here at work, when we talk about process flow or design or even deadlines we doodle, sketch or draw. We describe process ideas to each other in pictures. In fact, we even have a small selection of drawings that represent ideas and process.

 

 

Yes, that is a picture of some cats. No, it’s not a conveyor belt. And yes, we do have obsessions with Pie Charts.

We sketch out designs, relationships between components and user interaction. When I’m testing Call Centre flows I tend to draw pictures including people in them. This helps me see the flow of the calls more clearly. It allows me to use the image for guidance freeing my mind for further ideas and divergences. I can therefore see the flow and concentrate on other things.

 

 

Again, Mind Maps are diagrams that help to visualise the relationships between Test Ideas. I can mark Static Tests (Checks) and Exploratory Tests (Tests) easily on the Mind Maps so I know where we need to concentrate automated Checking and where Testing is needed. They form a natural Sketch of the ideas and work.

 

7. Randomness, Reversal and Reframing

 

If we look at the world in the same way, all of the time, we will develop a blinkered view, biases and consistent patterns that may generally serve us well. This is good for many circumstances, but when we are thinking of new Test Ideas and looking to diverge from the “Norm” it can help to reverse these views or reframe them. It tricks our mind in to thinking differently.

 

One of the ways I do this in an Agile environment is to look at the user story and reframe it.

 

We design stories like this:

 

As {Someone}
I want to do {Something}
So that I get some {Value}

 

What about reframing the story as {Someone} else?
Or mixing stories by combining the {Someone}, {Something} and {Value} from different stories?
Or how about thinking about all the other ways you could obtain {Value} without doing {Something} or doing something altogether different?

You’d be amazed at how many test ideas this can generate.

 

8. Improvisation

 

At first I disliked this suggestion in relation to Exploratory Testing because I didn’t deem testing to be improvised. Yet upon reflection and observing my own Testing I noted that I do improvise a lot. If I have a “hunch” I will use a tool to aid my testing. If the tool doesn’t exist I’ll try to make one or get some help from the Programmers.

 

I will react to new information at all times, plotting my journey as I go, always mindful of the end Goal or Charter. And I guess, you could call this improvisation, but I suspect it’s more exploration.

 

Yet I improvise with tools, note taking and ideas generation. Drawing a line between actual Exploratory Testing and Ideas Generation is a tough one for me, I think the ideas and the Testing combined is the true value for me.

 

Without good ideas I’ve always felt I’ve been left with Checks and not Tests. I’ve always felt like I’m confirming, rather than exploring.

 

9. Selection

As the authors point out “you can’t do everything” so a way to prioritise and select is required. When I list out my Exploratory Test ideas in a Mind Map I see patterns and groups starting to emerge; these could naturally be a selection criteria.

 

I believe in adopting a Wide Awareness Field which means opening my horizons to other elements of the business, the testing world and the subjects that interest me outside of work.

 

That’s why I try to find out what’s happening in Sales, Marketing, Support, Delivery and Operations at work.

• Are we seeing some trending user patterns from sales enquiries?
• Are we seeing a growing number of usability issues through support?
• Are the delivery team seeing problems with providing excellent service?
• Do we have an area of the product that consistently proves troublesome?
• Have we had some changes in an area that would warrant more Testing?

 

There is something the authors call Forced Ranking where you are forced to put the ideas in an ordered list with each idea having a unique rank. This is exactly the same technique many people use managing their story flows and product backlog. A list of the things we want in the product, ranked with the most important at the top.

 

I’ve tried this with my Exploratory Testing, but I’ve not yet found the best mechanism for handling this. Pivotal Tracker is excellent, but I’ve not yet found the right flow with this tool with respect to Exploratory Tests.

 

I suspect that with a growing Test Team we’ll start adopting a white board and sticky note approach to make it all visible to the whole team and business.

10. Try something new

The authors suggest simply trying something new with each Game.

 

It’s something I try to do, whether that be a new Heuristic or Mnemonic or a new Testing tool. I may try a new User Scenario or a new browser, or simply just approach my testing at a different time of the day. It’s amazing how your mood and energy levels effect your Testing.

 

I like these ten points as a way to start generating new Test Ideas and Conditions, as well as giving me a basic set of tools to analyse how I play games and how I use some Game Storming techniques during my Testing. They seem like a great starting point and the book goes in to much more depth about what is a Game and how to manage your Games. I found lots to learn in the book. It gave me a lot of ideas for creating the right environment to let my creativity flow. So….

 

How do you generate Test Ideas?