Testing: The Boardgame

Fengol

Title subject to change.

A couple of years ago I suggested a game that teaches the Systems Development Life-Cycle and, finally, I've taken those ideas and made a game and playtested it.

I'd like to call it a serious game for the software development industry; teaching the importance of quality practices like unit testing & code reviews.

The game can be played with 1 to 5 people and takes about 10-15 minutes to play.

The each player takes the role of a software development team trying to get their project to 100% complete before time runs out. At the beginning of the game the number of rounds is decided by drawing a card from a Time deck. The players also draw a percentage "Completion Bonus" card from another deck, and the first player to reach this point at the end of their turn gets this bonus.

Each round, each player takes a turn doing the following:

• Move 2 spaces OR Take 2 quality tokens OR Move 1 space and take 1 quality token
  
• Drawing a risk card
  
• Either move the number of spaces (normally backwards) on the risk or pay a number of quality token equal to the number of spaces they have to move
  

When the final round is played, the players draw an "Unforseen Risk" from the special deck and either move back the number of spaces or pay quality tokens. Then the scoring can begin.

• The first player to end their turn on or further than indicated on the "Completion Bonus" card gets 1 point.
  
• The first player to end their turn on 100% gets 2 points.
  
• Each player is awarded the bonuses they're on or further than as indicated on the board.
  

The player with the most points wins.

The point of the game is that if you take a "cowboy coder" attitude and try to move 2 spaces each turn without taking quality tokens, then you have the greatest chance of winning but you open yourself up to risk. On the other hand, you can't go too slowly building up quality token (i.e. taking forever with tests and code reviews) that you don't complete the project. The idea that players have hopefully learned is: Testing is important!

My next steps are improving the balance and building more polished pieces. I plan to share this with the company I work for and hopefully, they'll buy into the idea and sponsor building the final product as a training tool and marketing gift (i.e. they can slap their corporate logo all over it and give it out at events).

Aequitas

I worry that, since the the risk card you draw has a single number on it, that movement and token drawing become essentially meaningless, and the luck of the draw on the risk cards is all that matters.

You could essentially decide to "always move", and then you'd always have the best chance of winning, and it would all be up to the draw.

I think you could mitigate this by making the token cost on a risk card always be 1 less than the movement cost.

LexAquillia

I share @Aequitas's concern. Another way to resolve this could be to link "quality" tokens to to victory points as well ? So people get bonus points for the number of quality tokens they accumulate. The problem of course with this is that it could encourage someone to just accumulate quality tokens as a means of getting lots of VP's.

Fengol

We played tested this a lot, with "always move 2 spaces" versus "move 1 space, get 1 quality token" versus "1 turn take 2 tokens, next turn move 2 spaces" and they're all fairly evenly matched with the effects from the risk cards. The difference is that players who moved slower (picking up quality tokens) won more consistently.

And that's the point. IRL most developers dive straight in cowboy-style; no plan, no unit tests, no code review, nothing. And sometimes, they're lucky enough to get the project done "On time, under budget, at good quality" but they're relying on their luck and experience to get them through.

My game aims to point out that with a slower approach, taking the time to do proper quality control pays dividends towards the end of the project because you've been able to weather the risk.

And you really see it in the game. The guys who take push ahead often start out 2-3 spaces ahead of everyone else. But as more risk cards are played that they can't handle by about 50% project complete the guys who've taken the time to pick up risk cards start to over take.

But sometimes the cowboys do win. And that's OK, it happens IRL; and it's what convinces developers to stick to their guns and ignore testing and code reviews. It's the consistently winning that important (and what developers don't get right) and because this game is quick to play, it's easy to have a couple of games to show the strategy working.

@LexAquilla, thanks for the suggestion but I thought about awarding points for having extra quality tokens at the end of the game but it doesn't match the real-world model. The customer doesn't give you extra money because you have working unit tests; they only care that you've delivered working software.