Dice, dice, baby.
I was first introduced to James Bach’s¹ dice game by Peter Haworth-Langford, a lead QA at ASOS. The game involves a player (or group of players) and an instructor, and the only props needed are a set of differently coloured and shaped dice. The rules are simple:
1) The player rolls a set of dice before the instructor gives them a score. Then, the player must figure out how the instructor arrived at that number.
2) There are no other rules.
So, for example, the player would roll all of the dice, the instructor would then say a number (e.g. ‘17'), and the player would need to work out why 17 is the answer.
While this sounds simple, it’s actually pretty tricky to discover the relationship between the dice and the answer — many people playing for the first time are surprised to hear a number that doesn’t match the total amount of dots on all the dice.
I’m going to avoid mentioning the specific rulesets we used to generate the scores in this game, as they may be used again. If you feel inspired by this post to play the game, I highly recommend making up your own rules — they can be as simple or as complicated as you want.
Not only did I find the game fun, in a challenging sudoku-ish sort of way, it also struck me how well it modelled the test process. It teaches analytical thought — encouraging the elimination of variables, and shows participants how to think in new ways. Mostly, it forces you to constantly question your assumptions, which is an incredibly valuable ability to have as a software tester.
At ASOS, we take on a group of interns for a year, and, at the start of their time with us, they get to spend a day learning about different disciplines in technology. It was decided that we would spend a day teaching Software Testing, so my colleague Tanya Domke (another lead QA at ASOS) and I volunteered to run a session. It was an easy decision for us to choose to teach the dice game, as we’re both fans.
After deciding this, Tanya and I began practising the game on our colleagues within the Apps team at ASOS. My biggest takeaway from this was how differently people could approach the game. We had someone who wrote down the questions and results of each round into a paper notebook, someone who would only roll one dice at a time, another who hid the dice from us after each roll. We even had someone who refused to play after two rounds as he didn’t think it was fair!
What was also interesting was that different people would focus on different rules — some would focus on dice colour while some could only see the numbers. Mostly, it was a great experience, allowing us to practice teaching people the game and working out any issues before we taught it to the interns.
Our session with them finally arrived. After a quick intro, we split the interns into two groups, but gave them the same set of challenges. The biggest difference from our previous practice was the fact that we were now playing the game with a group, which created a very different dynamic. Some people would be more vocal, some would only guess sporadically. It transpired that being in a group presented both an advantage and a disadvantage. The first rule played was very simple, to the point that I was worried our (very bright) group of interns would work it out within a few rolls of the dice. In this situation, it turned out that being in a group wasn’t helpful, as I heard one intern mention the rule almost immediately, but it was lost in a sea of guessing. The group did eventually figure out the rule but had been tripping themselves over by overcomplicating what it might be.
For the second round, the interns were now a lot more prepared, knew how the game worked, and understood that they needed to eliminate misleading variables. To make up for this, we also made the rule more complicated (😈). It was great to see the group apply a much more methodical process in this round, and they were able to figure out the rule.
The third time we played the game, it got even more interesting. The rule for this stage was actually completely unrelated to the dice on the table. It took the interns a few minutes to figure this out. When they did, they started methodically investigating the rule like before: they stood up or sat down, they put their hands on the table, they even went silent for a couple of minutes and took turns asking what the dice score was. Eventually, they managed to work out that the rule was the cause of the results (it was fair, I promise!)
We also asked the interns to challenge us back with rules of their own. This was a useful learning experience for us and them. The first rule they tried was a very complicated mathematical algorithm, which proved too complicated to be able to work out quickly after each dice roll, and so had to be abandoned. The second rule was related to the number of people walking past a window in the office, we did manage to figure this out eventually and, were again, reminded to never trust assumptions.
In case it isn’t clear, I love this game. It’s a great learning experience for the players — and surprisingly, the instructors. Watching the types of assumptions that players would make reminded me how important it is as testers that we constantly challenge assumptions made by both ourselves and team members. This is particularly useful when integrating with an exterior resource, such as an API.
After we completed the exercise, we discussed the game and encouraged the interns to provide feedback in the form of tweets. Judging from the responses, they seemed to have fun, and more importantly, learned to always keep an open mind.
I recommend playing this game within your own development teams — and I’d love to hear your results.
¹James Bach is a software tester, author, and teacher who we’ve previously brought into ASOS to give a talk. His blog can be found at http://www.satisfice.com/blog/
Joe McGuinness is a QA Engineer at ASOS, where he works on its mobile applications. When he’s not at work, he’s probably either learning French, attempting to exercise, or at the pub. Definitely not in that order.
