Games and testing
Jun01
No, I don’t want to write about the testing of games, but last week someone pointed me on an article written on wired.com. The article was about the use of a game GUI on an email client. The application worked on attaching a number of tokens on the email to show the importance of the mail. More tokens made sure the email got the attention it required. The thing I thought was that the system could be misused, but within a company the system could work. De strength of the GUI was that it was based on a game. And with this game one could do his normal tasks on an easier and funnier manner. This is called serious gaming.
The idea of using game functionality on other tasks is interesting. How can we use this idea with the testing of software? Or can it be useful to add more fun (and functionality) to the testing of software. For me testing itself is fun. I like to make the defects and show the developers what is wrong. It is equally fun when my testing team makes the defects and finds (I can say it) faults. Maybe not the correct way to correspond it to the others in the project because testing is not finding errors but acknowledging the quality of the application. So why make it more fun? It’s already fun!
I would think the fun is less when your testing a system with a good number of test cases and the job repeatedly the same, thus boring. Sorry it happens! These things can happen a lot when testing huge applications or very parts with a high risk that should be tested as thoroughly as possible. Also when specifying a lot of test cases it can be boring to create the cases. Or when crowdsourcing your testing you need a pleaser to make other people give up their time to test your software. So sometimes we need to make it more fun.
Is using a game interface more fun? Yes, you can make a lot of things more fun with games, even serious tasks. There is a whole industry designed on creating serious games to make people do something or learn something new. For now we need to create a fun interface when specifying or executing test cases. I am going to try to give a few possibilities.
At first the defects need to be addressed. When you need people to find defects in software you can create a rewarding system for finding defects. For example: a low defect on the layout of an application could be set to one token. But that defect which dumps the system can be set to the collection of 20 tokens.
On the end of each day, week, month, … you can award the person who got the most tokens. It stimulates people to find more and more specific defects. This can also be done with the designing test cases. Those test cases which resulted in defects can get the same amount of tokens. The latter I prefer because it gives more attention on the most difficult tasks in testing, creating good test cases. It can be fun for others than testers to also join a test team. Your testers will like it.
![]()
It also can be fun for people in the project other than testers to also join a test team. They will like it in trying to get more tokens compared with testers. This also applies to end users who need to be envolved on the user acceptance test. And the end of the project you could even have a high score list!

An other option is the creating of something as a product risk analyses. This also can be done by incorporating it in a game. I normally spend a lot of time in trying to convincing people we need to do a good product risk analysis. To really know the risks and test those parts which need to be tested. When I can use something of a game interfaces around this process it would become a lot more attractive to some people and even easier to understand. With my stakeholders I could analyze those risk and the results of these risks. When they are known I could incorporate these risks in a game to show the results when we do nothing. I can use “Mario” to undergo the risks we’ve identified and show them to my stakeholders. If they think we are missing risks or have to much it is easy to “see” these.
It all is an opportunity to motivate your team in doing the things they should be doing in the way you want them to do it. In the past the use of games has acknowledged a better use of systems and activities. So why not try them on testing software! And get on with serious games and testing.