Just back from STARWest in San Diego.
The hotel was great and so were the attendees I ran into. Well, it was easier to run into some mainly because James was in fine form drawing a mob around his tester games in the main walkway.
Class was in session, even when it wasn’t. To me, that’s the mark of a good conference.
I had emerged from a session to find about 30 people crowded around him. He was like a chess master, playing his dice game with 3 people at once. He always carries three bags of about 30 dice each with him wherever he goes, and he seemed to be using every one of the dice in those bags.
Knowing the operating premise of the game, I decided to help him out.
He looked over and saw me, and told me he was glad to see me and could use my help because he had to go meet someone. I’ve never had to follow James after he finishes a talk, but this was as close as it got — I inherited his crowd and did my best to keep the momentum.
He got back a few minutes later, glad to see the party was still happening. But he noticed that the bags of dice were all laid out on the table — all 100 or so of them. He seemed annoyed.
“Hey, man! My dice are all mixed up!” he said.
I had no idea that the dice had an organization to them. I felt bad, but I told him there was no way for me to have known that.
Still, this was not an impossible problem to solve. The “dice game” is about recognizing a pattern in James’ head. You do this by rolling dice. After each time you roll, he says a number. You have to figure out why he’s saying what he’s saying. It’s fast feedback from testing, and you have to form conjectures just as fast — then you roll the dice to either confirm or refute your conjectures. You win when you can describe the operating pattern to a high degree of certainty.
Welcome to testing. Fast, fun, and authentic skill-building.
But back to James’ annoyance. I replied, “ok, then, don’t tell me how they were organized in the bags. Let me figure it out with you giving me feedback as I do it.”
He seemed to lighten with the perspective of that challenge. But before we could make this into a game, he said “Each bag uses the principle of requisite variety.”
I knew what James meant by that. It’s one of the many terms to describe tests. In this context, it meant the bags were equivalently and sufficiently diverse.
The first thing I wanted to do was make sure the crowd knew this was spontaneous. I wanted them to know this was something new between James and I, so they could pitch in to help if they wanted. Like everyone else at conferences, he and I follow threads of ideas that pique our interest. I had no idea what was going to happen, but I knew it would be fun, interesting, and meaningful somehow, and I hoped the crowd would play along as James tested me.
So I took all the dice in one big (laid-out) pile and scanned for affinity. It quickly emerged that there are several ways to make affinities. The ISTQB folks want you call these “equivalence classes”, and that’s fine, but they don’t tell you what to do when you suddenly realize that many tests might belong to more than one equivalence class.
For example, a red translucent die with black pips could go in 5 categories: red dice, black pipped dice, lightly opaque dice, dice that were identical to it, and approximate size to other dice like it.
My aim was to quickly take stock of the primary dimensions that stood out to me, then group them by those properties. There was background color, size, shape, pip color, pip type (dots, numerals, or symbols), opacity, albedo, elasticity, number of dice that were identical, and weight — and many fit in more than one category as I sorted them, so the notion of “equivalence partitioning” was difficult.
Good thing I remembered the context. These dice are for games. The point is to have three bags that are equally diverse such that the odds are greater of having a similar experience no matter what bag James reached for. If one bag had too many of one kind, or not enough of a different kind, that may stall the exercise or the lesson he wanted to teach.
So I grouped mostly by “similarity to each other.” I grouped the white dice together, the red translucents, the small standard blues, the more-than-six sided, the “few huge” (relative to most of the others), the ones with numerals instead of pips.
Then someone noticed that in the red dice pile, some had black pips and some white.
I took the suggestion to separate those into two piles.
In the white dice pile, someone noticed a few felt like they could be “eraser” dice — they had a rubbery consistency to them — which brought another dimension to dice: “the tendency of the pips to wear off with heavy use.”
I separated those.
Then I just did a straight count of each affinity and divided by 3. If it was not perfectly divisible, someone suggested I make a separate pile — a kind of Holding Pattern / Issues List pile to check with James about his preference for which bag they were most appropriate for.
The exercise took about 5 minutes, and with James as my “onsite product owner”, the mission was done when he grabbed the last 5 “issues list” dice and threw them into two bags, as if to say “good enough” (translation: further sorting into deeper affinities would be a waste of time and resources).
Too cool. Mission accomplished with a potential blog idea (mission accomplished there, too).
That was my best class that day, and a classy way to have an impromptu experience about class.