Jenga

30		4 - 30		Testing
minutes		people		Quality

What you can learn

This game is a great way to teach people the benefits of testing early and in smaller batches, before development is complete. This simple game demonstrates how it is actually faster to test earlier.

What you need

• 36 Jenga blocks per group of 6, number each block from 1 to 36. Be sure to write the number with a permanent marker on each side of the block (i.e. 6 times per block).
• Handouts with 4 bug numbers for each round. Pick any 4 numbers between 1 and 36 for each round. For example: 2, 17, 21, 36. You need one copy of the numbers for each group.
• A stopwatch or timer
• A flipchart or whiteboard to write up the results

How to do this

Split people into groups of 4 to 6. Try to have the same number of people in each group. Explain that the goal is to build a tower with Jenga blocks. The requirements are that the tower must use all 36 Jenga pieces and must be at least 4 Jenga blocks high, with the blocks stood up on the small end - see the picture below.

The tower does not have to be built like it is in Jenga when the game starts. Some people assume this, if they do, don’t correct them. It leads to a great teaching point since it makes fixing the bugs particularly hard. If people ask tell them they can build the tower however they want as long as it meets the requirements.

Round 1

Before the teams start to build ask each team to nominate two people on their team to be testers. Ask the testers to come forward and brief them separately. Hand the testers from each group the list of ‘bugs’ for the first round. This is just a list of 4 numbers between 1 and 36. Explain that they can’t show the bugs to the builders on their team, but once they have finished building the tower, the testers must find these ‘bugs’ and remove those pieces from the tower. If the tower collapses when they are removed, it needs to be rebuilt. The end result needs to meet the original height requirement, but the tower must be built from only 32 pieces (i.e. the original 36 without the four ‘bug’ blocks).

Once the testers return to their teams, let everyone know they can start and that they should let you know when they are complete. Start a timer at this point, so you can track how long it takes for each team to finish. Make sure testers don’t reveal the bugs until the end. Once people finished, capture the time it took for each group. Only take the time once the tower is complete without the ‘bugs’.

You can write the results on a poster like those shown below.

Round 2

Ask everyone to breakdown their towers for round two. Again give the testers four numbers for the ‘bugs’. This time tell them that they can test the tower after the builders have placed nine blocks. They still can’t show the team the bug numbers, but after the builders have placed nine blocks, they can tell them if any of the blocks are bugs. The builders can then remove them and continue to build. Once against start a timer as teams begin, and update the times on the score sheet for round two. In most cases the time should be less than the time for the first round.

Round 3

Again ask people to breakdown their towers. Hand out the bugs to the testers. Make sure you use different numbers for each round so that builders don’t start to guess what the bugs will be. It’s okay for teams to all get the same bug numbers though. This time let people know that the testers can check after each block is placed, and that block can be removed immediately if it is a bug. Again keep track of the time. It should now be significantly less that the first round.

Round 4

Let people know this is the final round. Sometime people can start to wonder how many times they need to build a tower at this point. Ask people to break down their towers, and hand out the bugs. This time tell the testers they can share the bug numbers with the builders at the beginning, and that they can use that information however they like. Most team immediately remove the four bugs and then build the tower. Double check though because occasionally team forget to put the bugs aside and end up including them in the tower even though they knew they are bugs in advance. Write up the time for the final round.

Debrief

Now debrief the game. Start by asking people what they notice with the times. In our experience the times for the last two rounds are fractions of the original time. Below is a copy of the results from one of the times we have run this game.

Some other questions which are useful for the debrief are:

• Which round feels like how you work today?
• Which round is how you would like to work?
• How did it feel to fix bugs in the first round?
• How did it feel to fix bugs in the other rounds?
• Do you think testing early takes more time, if so do they results change your mind?
• Do you think round four (knowing the bugs in advanced) is possible in software?
• In which rounds were testers more involved? ###How we’ve used this We use this simulation whenever we introduce agile testing as a concept to a team. It demonstrates really easily how much of a time saver it is to test early. It’s a great way to start a workshop on agile testing. We especially love the last round (our own addition to the game), which helps people think differently about testing, and introduces the agile testing principle of preventing bugs rather than finding them. ###Who shared this with us Nanda Lankalapalli