Balanced scoring: Codes of all five colors are necessary to win as the least codes determine the score.
Resource management: A player's mix of codes is determined by input from programming and design and used for testing so planning for the right mix is important.
Interdependence: The players cannot test their own test cases so they must set up test cases for each other that are not too easy, nor too difficult, to get a return on them.
Deduction: Each failed test case gives clues to improve the odds of passing it next turn.
Open end: The potentially high end game score makes every game open until the very end.
Educational: The game teaches agile testing in a game context
The first test game Find the Bug! became very popular in the test community. Being a game focused on
V-model testing, it naturally gave rise to questions about games more towards agile testing.
However, since I didn't have much experience in agile testing, nor any good ideas about how to turn
agile methodology into game mechanisms, I didn't pay much attention to that.
But then came several inspiration sources to me at the same time. One was a negative experience of
an agile project, where the test-driven methodology was abandoned in favor of a forced and undocumented
delivery of untested code, since defects could be put on a backlog anyway. Another was the brilliant
but sadly underrated game Alchemist,
which used simple mechanisms to capture the idea of mixing potions towards a predefined goal. This is very
similar to how test-driven development aims at testing code until a predefined test case passes. As if this
wasn't enough, I was asked to prepare a speech about how games can be used to teach testing to submit to the
test conference EuroSTAR, using
Find the Bug! as a physical illustration. Wouldn't it be great to show games both for V-model testing and agile testing?
Last but certainly not least, the next contest at The Game Crafter was the
design a game with a learning objective. Find the Bug! Agile simply screamed to get designed!
The initial idea was very simple. Collect codes (cubes) and create components (tiles), similar to how potions
are created in Alchemist.
Then spend them on other players' user stories (cards) to test for the right combination of codes, similar to
how you guess combinations in Mastermind.
Failed tests would give codes to the product owner while passed test cases would give victory points -
the more integrated user stories, the more victory points. Just like Find the Bug!, this agile cousin would combine
fun game mechanisms with good learning points.
But in spite of the simple idea there were many questions that needed to be answered. How many different codes
should there be? How many codes should be used as input and how many codes should be used as output? How should the
game encourage a natural flow, where players set up use cases for each other? How should the game be balanced,
so that the tester and the product owner both get a fair share of the reward?
As often before, I resorted to a spreadsheet to answer the questions. After some iterations, I decided to
proceed with five colors in total, of which two may be used as input and two as output. The rationale behind the
number of colors was that five colors can be paired in twenty combinations (if Color 1-Color 2 and Color 2-Color 1 are counted as
two separate combinations), which is a reasonable number of user stories for a short game. The rationale behind the
two input-two output mechanism was to make the individual combinations equally attractive (who would want to use
3 codes as input and only get 1 code as output?) and make it easier to split the reward between the tester and
product owner by letting them have 1 each.
For the actual testing or the guessing game, I used the Master Mind mechanism of letting the product owner
give clues about the results (fail if all are wrong and partial pass if only one of the two is wrong).
The decision to reward the product owner with codes and the tester with victory points was a design decision
supported by simulations. The design decision allowed two different strategic paths and the simulation
ensured that the two paths were balanced. (See Rules for the details.)
For the integration of components into modules, I wanted to create the image of a growing system where
more and more data flows in and out. By requiring the components to be arranged in distorted columns, each
component would have to feed and be fed by two other components. However, such a component would become wider
and wider, requiring more input but also giving more output, and creating an incentive to simply hoard codes
until the other players have prepared the components for you to integrate.
This turned out to be more difficult than expected. First I considered a hand size limit of six,
a number often seen in other games (like Tigris & Euphrates).
This would allow the players to have at least one of each color and only allow three
components to be executed, since each component requires two input codes each.
This seemed to solve the problems but was not very elegant. A golden game design rule says the gameplay
should be restricted not by rules but rather by strategy. For this game, I would have to find a mechanism
that would allow code hoarding but make it bad. I found three.
First, I introduced the ability to copy other players' codes. The more codes you hoard, the more do you help
the other players replenish their codes.
Second, I increased the reward for product owners and testers to
be given once their components get integrated. This would give them an incentive to deliver components in time
and with the right quality (i.e. that can be integrated). Not only an elegant solution to the game problem but
also a thematic one!
Third, I made it easier to integrate modules without too many codes. The more "missing links" in the
module, the more open input slots to put codes in. Again, the theme helped me find the solution.
Real test environments uses stubs where
components are missing so why couldn't I do the same? By letting stubs skip one level and link
components with one level between them, codes at the first level could flow through many more levels.
With that, I could focus on tests and rule reviews. The components were fairly few and simple; the
codes could be represented by wooden cubes for a more concrete test feeling and the components only had
to show input and output. I decided to stick to the black and green color scheme of Find the Bug! and
reuse the labyrinth-like pipes from Mice in a Maze. I even got to reuse
the first but rejected bug image for Find the Bug! by adding longer legs to it to make it look more