Rule summary

The player who finds the most bugs wins.

The application is represented by squares on a game board and the bugs by tiles drawn from bags. There is one bag for each column and one for each row. The players take turn to allocate testers to one of three tasks to find as many bugs as possible:

Analysis: Check if a bag contains many bugs or high value bugs (as indicated by a colored gem; green, yellow or red)
Test: Place a tester on a square on the game board and draw tiles from the bags connected to that square
Build a tool: Place a tester on a column or a row for use for the retest phase of the game (see below)
When all testers have been placed, the found bugs are placed in a bag and used in the retest phase. The more bugs found in a column or row during the test, the likelier it is that bugs will be found there during the retest. A tester building a tool will find all bugs along that column or row in the retest phase. However, a tool can only be placed there when all the bugs in the test phase have been found. If they are built too early and another bug is found in the test phase, the work is lost and the tester removed.

The challenge of Find the Bug! is to use the information acquired through the analysis tasks to place testers on the right squares at the right time.

Version History

1.2: Integration and performance test added
1.1: Negative "unfun" scoring removed
1.0: First edition

The complete rules are available in the PDF file to the right. In the following sections, I will describe how they came to be.

Implemented Rules

There are many ideas that came to live in Find the Bug!^©. On this page, I would like to present some of them and explain the reasoning behind them.

The game board

The game board had to satisfy two conditions: squares in several dimensions to allow analyses from several perspectives and squares in groups to allow more than one player to test a group. Two dimensions fit the theme well (business criticality and technical complexity) and so did three times three groups (three-tier architecture). Four squares allowed most but not all players to place testers and gave a total amount of 36 squares - enough for a short game.

The tasks

Analysis

Without the analysis task, the test task would simply be a random placement in search for bugs. This could still have worked with mechanisms similar to Memory but I wanted to weave in the possibility to draw conclusions about the bug probability (or bug density) in the game. First I thought of arranging piles with more or less bugs and lay them out on chess board but the setup would have been too cumbersome. Preparing bugs with more or less bugs was much quicker and the addition of a colored gem gave two clear decisions: look for a bug immediately or look at the stone first to assess the bug density.

Test

The test task is basic task of the game, so basic that I first didn't consider any alternatives to simply take tiles and see if they contain bugs. However, testing is not only about knowing when to start testing but also when to stop testing. Ideally, players should place testers according to the bug density but in reality, they placed all testers at the bug dense parts and no testers anywhere else.

Why? Simply because even if bugs have been found in a dense area, they were more likely to find more bugs there than in any less dense area. The option to return the first tile was a two-fold solution. The bugs in the dense areas will be quicker to find, no longer requiring all four squares to be tested, and the bugs in the less dense areas will be easier to find, making an attempt worthwhile when the other bugs have been found. This simple solution made the game much more similar to real testing!

Retest

There is a balance between analysis and test as the players must decide how much to analyse before they start testing. But once they've started testing, there would be no decisions left. The retest task gave them another balance decision: is a part of the game board free from bugs or not? By introducing a retest session (with distribution of new bugs dependent on previous bugs - just like in real testing!), I gave then the decision to either continue testing or to assume that a range of squares is free from bugs and retest them all with a test tool (but risk losing the test tool if more of the old bugs remained after all).

The bugs

There are a lot of calculations behind the bugs. Too few makes the game too random and too many makes the preceeding analysis redundant. Also, the choice between analysing severity of bugs (business criticality) and number of bugs (technical complexity) must be equal. Finally, there must be a spread so that each component is likely to have a unique severity or number.

The current distribution is a total number of 3/6/9 bugs in the 3 modules and a total severity of 3/6/9 points in the 3 tiers. Since bugs in both modules and tiers are required to count, the expected numbers are about half: 9 bugs and 18 points. A random strategy have 36 squares to test while an analysis strategy limits the search to on average 24 squares. (In the best case, the 12 "best" squares are found and in the worst case, it finds the average squares and doesn't limit the search at all.) The possibility to return the first tile further improves the odds. The table below summarizes the expected result of the different strategies:

Strategy		Module bugs	Tier bugs	Bugs	Points
Analyze module	(return tier)	0.4167 (1-14/24)	0.75 (1-(18/36*18/36))	0.3125	0.4688 (15/10*Bugs)
	(return module)	0.6354 (1-(15/24*14/24))	0.5 (1-18/36)	0.3177	0.4766 (15/10*Bugs)
Analyze tier	(return tier)	0.3889 (1-22/36)	0.8594 (1-(9/24*9/24))	0.3342	0.4297 (18/14*Bugs)
	(return module)	0.5926 (1-(24/36*22/36))	0.625 (1-(9/24))	0.3704	0.4762 (18/14*Bugs)
Random	(return tier)	0.3889 (1-22/36)	0.75 (1-(18/36*18/36))	0.2917	0.375 (18/14*Bugs)
	(return module)	0.5926 (1-(24/36*22/36))	0.5 (1-18/36)	0.2963	0.381 (18/14*Bugs)

A player may thus choose a random strategy with more testing attempts, a low-risk analysis to find many low severity defects or a high-risk strategy to find few high severity defects. The analysis strategy pays off after 5 turns (when 5 random tiles equals 1 analysis + 4 planned tiles), although analysis is also useful to determine when a module or tier is bug free and ripe for a test tool. The possibility to adapt one's strategy to the other players' placements and the random distribution still makes each game an open affair. The reason players may return the first tile is to remove some randomness and to give some reward to analysis (as players may take 2 tiles from the bag they are most uncertain of).

The task restrictions

The tasks have some restrictions that are important for the game to flow:

Players must choose different analysis tasks. Without this rule, a player could analyse the same task as the player before her and then, since the turn order is reversed every second turn, use the information first.
Players must choose different components for their first tests. The purpose of this rule is to make it more difficult for a player to use another player's information and place a tester in the same square. Nevertheless, the players should be able to use the information in some way so from the second tester they are free to choose again.
Players must choose different test tools. This rule gives the player who risks building a test tool early an advantage but the cost may be high: if built too early, the effort is lost.

Rules (Video)

Rules (PDF)

... and Rejected Rules

There are of course also ideas that did not make it and here I explain why.

Hidden test result

To make it even more difficult for players to follow in each others' foot steps, I considered letting them hide the test result and not tell the other players whether they found a bug or not until next game turn. However, not only did I want the players to be able to use the information to some extent but this rule would also delay the building of test tools as it takes 1 more turn to assess whether a module or tier is free from bugs or not.