The objective in Find the Bug! is, as the name indicates, to find bugs and bugs can be found in the test phase or in the retest phase. At your disposal, you have testers that can be assigned to one of three tasks: analysis, test or retest. But before investigating those options, let us first look at how many bugs you can expect to find.

For a bug to be found in the test phase, a bug must be drawn from the module bag (6 of 12 tiles) AND from the tier bag (3, 6 or 9 of 12 tiles). This gives the following expected numbers and values of bugs:

Tier with 3 bugs: 3 components with 0+0 bugs and 9 components with 0+1 bugs = 0 bugs

Tier with 6 bugs: 3 components with 0+0 bugs, 6 components with 0+1 bugs and 3 components with 1+1 bugs = 3 bugs

Tier with 9 bugs: 3 components with 0+0 bugs, 3 components with 0+1 bugs and 6 components with 1+1 bugs = 6 bugs

Module with low severitiy: 2 bugs worth -1, 2 bugs worth 0 and 2 bugs worth 1 = average value of 0

Module with middle severity: 2 bugs worth 0, 2 bugs worth 1 and 2 bugs worth 2 = average value of 1

Module with high severity: 2 bugs worth 1, 2 bugs worth 2 and 2 bugs worth 3 = average value of 2

For a bug to be found in the retest phase, a tier and a module that intersect each other must be among the 6 tiles drawn. Given the information above, we can expect 2 tiers and 1-2 modules to be drawn, giving an expected number of bugs of 6 or 8, worth 3 or 4 points (or 1-2 points if shared between two testers).

With this knowledge, let's now look at how to dispose of the testers. A tester randomly given a test task has 25% (9 bugs in 36 components) chance of finding a bug. An analysis task may in the best case identify the tier with 9 bugs, increasing the odds to 50% (6 bugs in 12 components). An identification of the tier with 3 bugs is also good, since you know which tier to avoid and increase the odds to 37.5% (9 bugs in 24 components). The worst finding is the tier with 2 bugs, which does not increase the odds at all. The odds apply to analysis tasks in modules as well with the difference that they refer to expected value of bugs rather than expected number of bugs. A tester randomly given a test task score 0.25 points and so on.

Thus, one analysis task increases the expected value of bugs from 0.25 to 0.375 on average. Two analysis tasks, one in a module and one in a tier, increases the expected value to 0.5625 (0.375% * 1.5). This is slightly better than for example two analysis tasks in a tier, which would only increase the expected the value to 0.5. A third analysis task would increase the expected value to 0.78125 (0.5625 * 1.5).

So where do all those probabilities lead us? The answer is that you have to take into account the pay-off time for a tester. It sounds good to increase the expected value to 0.78125 but if you don't have enough testers to actually assign to testing tasks or if all the bugs are found by the other players, you have no use of your analysis. Thus, you need to include your available testers (which depends on the number of players) and the actions of the other players in your strategy. The list below shows the pay-off time.

0 analysis tasks: Expected value per tester is 0.25

1 analysis task: Pays off after 3 tests (expected value for 3 testers is 1.125 compared to an expected value of 1 for 4 testers with no analysis)

2 analysis tasks: Pays off after 3 tests (expected value for 3 testers is 1.6875 compared to an expected value of 1.5 for 4 testers with 1 analysis)

3 analysis tasks: Pays off after 3 tests (expected value for 3 testers is 2.34375 compared to an expected value of 2.25 for 4 testers with 2 analyses)

In addition, you should also observe the other players. What do they analyse and how do they react on the information? If someone seems to have found good places to test, you should take advantage of that rather than wasting resources on analyses. If other players do analyses as well, one or two analyses are usually enough.

Finally, don't forget to save 1 or 2 testers for the retest. A successfully placed tester will find bugs at a value of 1 if shared with another player or 2 if found alone. This is better than any of the expected values in the test! As soon as "all" bugs have been found in a tier or a module (that is, when the expected number of bugs as listed above have been found), you should claim the test tool and the points.

Find the Bug! still requires luck to win but by understanding your odds, you will help your luck on the way!