Dice game: Key life skills for testers

Back in November 2010 I had the chance to attend Michael Bolton’s excellent Rapid Software Testing course in London.  Obviously for me this was a fantastic opportunity & experience.  From those three days with Michael I had one thing that really stood out.  Although not for everyone, the dice game that Michael & his colleague James Bach tour the world playing with students, for me really emphasises some key essential skills for any software tester.  I had enjoyed it so much that as soon as I’d returned I quickly set out to purchase the props required to play it with my colleagues.

If you’re not keen on learning about the background and the challenge itself, scroll down to lessons learnt.

The Rapid Software Testing challenge

So it all started at the end of our Rapid Software Course.  Thursday the 4th of November; I remember it well as Michael had been enjoying playing the role of a problematic stakeholder, who’d just wanted stuff done for the past couple of days.  This challenge wasn’t any different; he still gave very little away!

So Michael explained the rules of the dice challenge & laid four different coloured sets of dice on the table.  Each colour  set contained five dice, so twenty in total.  The rules were simple!  Roll the dice.  In response to this, Michael would say a number.  Then you’d have to reliably predict the number that Michael would say, and you’ve won the game.  Yeah that’s real simple I thought; can’t be that hard right?

We were split into four groups; each group had three to four people in it.   We begun discussing amongst ourselves our plans & all very quickly had begun rolling dice and making guesses as to what the pattern could be.  Michael progressed around the room responding with a number of his own, which sometimes matched our guesses and sometimes didn’t.  Good fun & very frustrating at the same time!

For myself I found it extremely difficult working with two people who I didn’t know very well.  We were all very strong characters & each of us wanted to try our own approach & tactics.  We’d started out a bit of a mess!  I began to note down responses in accordance with the factors that I was observing.  Then things began to improve.

After some time we believed we had cracked the pattern and proudly announced to Michael that we had solved this puzzle.  Chuffed we were!

Michael said something along the lines of “Ah! ,Very good!”.  Smug we were!  Then he ran a test that tested us.  He rolled the dice, and we weren’t able to guess the right number after all.  Before we knew it the problem had been solved by another team!  How did I feel about this?  Well I was pretty gutted to be honest!  I like to win things like most people & to fail; well, that kind of sucked!

Michael then went on to explain the pattern & congratulated the smug bunch who’d cracked his puzzle.  Fair play to them though; they’d solved the pattern; or at least one of them did I forget who.  I remember Peter Houghton being part of that team; a man who is now also a fellow blogger.  Perhaps it was Pete I honestly can’t recall.

After a debrief from Michael on the challenge, it was a quick chance to say goodbye; shed some tears & hug each other like all real men do.  Well not quite, but we did get to say our goodbyes

Trying it with colleagues

So I’d returned home & quickly set out to buy the required props.  As soon as they’d arrived my fellow Glasgow based test team colleagues Andrew, Chris, Michael & Stuart all got the chance to become what would be know as “Victims” of the dice game!   They were joined by around another five or six developers, a graphics designer, a couple of team leads & a documenter over the next few days.

We’d just finished our Friday conference call with our team members in Jakarta, Indonesia.  I’d pulled out some dice from my bag & grouped them into colours.  Five dice for each of the four colours, twenty in total.  Each person received their dice & I begun to explain the rules of the challenge to them.

You can gather they were a bit sceptical by now   Firstly my rules got them a bit riled up & secondly the challenge was pretty famous.  Most had heard about it & had a small inkling of fear, gradually increasing with each previous day that I’d harped on about wanting to pose this challenge upon them.

So we progressed & I think it took them about forty minutes to eventually solve it.  In fact, they only managed to solve it once our boss Michael had left the room, as he was effectively leading them astray by over complicating things, despite my best efforts to tell him this!  “You’re over complicating things!”  Baffled look; followed by another attempt.  “You’re still overcomplicating things!”.  A very smart guy who through a series of events in the challenge (patterns found) began to doubt that any other valid pattern existed.  This other pattern was of course the one that I was looking for.

Michael, Andrew & Stuart if I recall correctly all identify one or two very valid patterns.  I was pleased for them, really!  However as I’d explained to them “Yes you’re correct, that’s a very valid pattern! *Long Pause* However it’s just not the pattern I’m looking for.  Which is indeed a very valid pattern, like your own.”

Over the next few days that phrase became very common.  My poor colleague Gerry who sits next to me had probably heard this at least fifty times.  He chuckled inside himself a few times having been one of the first dice game “victims”.  Those chuckles progressed to laughter, followed by collaborative laughter.  In fact, near the end we had people hoarding round the desk laughing & seeing if people would get it!  By this time Gerry’s laughter had turned to tears of distress!  Gerry if you’re reading this I’m sorry for putting you through that!  I do like you & I hope one day you’ll find it in your heart to forgive me   For non Scots just insert sarcasm tags between those last two sentences & you’ll get it

Our graphics designer at the time took several attempts at this & couldn’t quite manage to crack it.  If he actually sat down and kept trying he’d probably have solved it pretty quickly.   The video below is Gerry trying to coach him into solve this challenge.

So a bunch of people attempted this with me & pretty much everyone enjoyed it.  A few people left feeling it was a waste of time.  Some had really enjoyed it & quickly spread the word.  Some people got it!  When I say got it, I mean they actually saw the benefit of doing this challenge & could see how aspects of this would directly apply to their day to day job as developers, testers & so on.

Lessons Learnt

Myself, I’d realised these lessons the first time I’d participated in this challenge.  Sitting on the other end of the table & watching how others tackled this challenge, was for me insightful to say the least.

Learning from others approach to testing

I’ve talked in the past about learning from the approach that others take when approaching a testing challenge.  When I say challenge, this could be anything from an actual testing task such as developing a test plan, communicating problems with stakeholders or actually testing a piece of functionality.  It could also be a challenge internally with other members of your team, such as this dice game or some of the other challenges myself, or others have did in the past (The usability challenge,  Escape, the impossible challenge, testing the future, the Friday challenge).

I honestly believe, and from my experience have learned that my most valuable testing insights have come just from watching, analysing or investigating how others have approached a challenge.  I’ve also learned a lot just from thinking about how I’ve approached a challenged myself.  A prime example which I later went on to share here on my site was the keyword based testing technique I’d used to tackle my colleague Stuart MacDonald’s challenge “Testing the future”.  I’d highly recommend you take a step back sometimes & look at how you or others have approached a challenge to see what you can learn from it.

Tackling the challenge

So lets summarise what people did to tackle the famous dice game challenge:

• Simplifying problems
  • Only one or two people actually started out simple.
    • Most quickly lost track & made it difficult for themselves.
      • Some managed to regain focus.
  • Most people over complicated things.
  • Some people kept trying the same things, often!
  • Eventually most people realised that it helped to simply their problems.
• Focus / Defocus heuristic
  • Some people took the instructions very seriously.  Others questioned and challenged the constraints.
  • One person focused / defocused that much that he’d cracked the challenge in only three minutes.
    • The next closest did it in ten!
      • This doesn’t make either of them special in any way!  More on that later.
  • One person explained their approach was actually to use focus / defocus heuristics to solve this problem.  Just like he solves his coding problems.
• Assumptions
  • Yes people made lots of these
  • Very few people questioned their assumptions initially
    • Most people had questioned the ones that they were aware of in the end
    • The people that did question them tended to crack the pattern quicker.

So you can quickly see three common trends here that helped people solve the challenge quicker; simplifying problems, focus & defocus heuristics & assumptions.

Simplifying Problems

Those that started simple quickly developed a good mental testing model of the problem.  Obviously this is a key skill for any tester to be able to take a complex problem and break it down.  By simplify problems we not only allow our model to quickly develop, we also gain much quicker coverage & as such negate risk.

Anyone can test!  Being aware of key skills to make you an effective & efficient tester will set you aside from the rest.

Obviously simplifying problems isn’t always valid.  Why?  Well examples could be that simple has already been done by others?  Perhaps simple doesn’t produce any results.  Perhaps the project is that complex that simple in itself will take too long to work out & or achieve.  That’s were risk comes into play.  It always pays to be aware of the key risks when testing something.

I remember a previous project that was testing initially by simplifying the problem then progressing to more complex tests.  A good initial strategy!  Now one plus one equals two right?  Well whoever had tested this piece of functionality (I honestly can’t recall who it was) had obviously started simple.  Now a common test when simplifying a problem is to take one thing & add another right?  So they did this and it quickly passed.  However they’d only simplified in a context that they were aware of.  Another context could have been users of the feature.  If they’d simplified this and done their one plus one equals two they’d have found it failed terribly!

So not only is it good to be aware of the context of something it’s also good to be aware that everything is fallible.  Simplifying, risk, context, focus / defocus & assumptions are all fallible.  As long as we are always aware of that we can attempt to counter possible fallacies.  Like defects we’ll never catch everything, we will though become better testers from improving our awareness of unknown unknows & of course known unknows.  Much like we would be aware that from simplifying a problem, focusing & defocusing & making assumptions,  all these can have negative effects along with their positives.

Focus / Defocus heuristics

This I find is extremely challenging & very rewarding when I can achieve it successfully.

Some examples I find help me focus / defocus are:

• Context revealing questions
• Switching my thread of work & returning later
• Simply taking a break
• Thinking how others would solve this

There are probably a few more worth mentioning, I just can’t think of them just now.

Context revealing questions is a good one & one I can provide a good example from.   In my role as a tester I’m often required to, or asked to provide feedback on the initial scope of a project be that one I’m responsible for or not.  Often by the time I’ve joined we have a list of requirements in the form of simple user stories.  Very minimal, not in depth & will often be fleshed out into more stories and/or sub stories of those stories at a later date.

I use a simple mnemonic to test these requirements “WWWWWH/KE”.  Which is simply who, what, when, where, why & how combined with my knowledge and experience.

• Who is this for?
• What is this for?
• When & by whom is it be done?
• Where is it being done? (Location code/team)
• Why is it being done? (What problem does it solve?)
• How is it being achieved?
• What questions does my knowledge of this or related products/systems produce?
• What questions does my experience of this or other related products/systems produce?

Obviously knowledge & experience are closely related & our experience might drive more passionate feedback due to direct interactions.  All of these obviously have one thing in common.  They provoke thoughts and lead off into sub questions of their own.  This allows me to quickly focus and defocus on what’s important & provide useful feedback rapidly.

This likewise could fail; we know that because everything is fallible.  Why?  Well, we could become too absorbed by over analysing requirements & overwhelm our recipients with the amount of feedback we’ve given.  The feedback itself could also provide little value.  The time taken to gather that feedback, could breach key deadlines.

Assumptions

I’ll not go into assumptions as I’m pretty sure we all know the negatives of these.   In fact I’ve talked about them a lot in the past.  I’ve talked about my experience in making an assumption & missing expectations of the actual challenge when our team was presented with what I’d deemed the impossible challenge.  It’s worthwhile mentioning that although we should try our best to be aware of assumptions that we make.  We will never be aware of all, or even most of the assumptions we make.  More importantly being aware & actually doing something about them makes a huge difference.

We can actively question our assumptions as we make them.  It is also worth asking yourself which of these assumption that I am aware of are worth noting?  It might help identify risk, provoke discussion or even make itself into some formal documentation such as a features test plan.

Does time actually matter?

You can certainly see that there is indeed a lot to be learned from a simple game of dice!   We can also see that cracking the challenge doesn’t actually matter, or even doing it in the quickest time.  Some people get hung up on this factor!  I know myself I wanted to be the first to crack it as I felt it was important.  Even James Bach himself has commented on how students who’ve quickly solved this challenge will do well for themselves.

It’s what we take from it that counts & how we apply those aspects to our daily job as testers, developers, managers or whatever.  Simplifying problems, focus / defocus & attempting to be aware of our assumptions are key life skills for anyone.

So that’s it!  This was a fun exciting little challenge that had inspired me to learn more about myself & others.  It inspired me to become a better tester, like all good challenges do!

Thanks for reading.

No related posts.