Test Coaching and Collaboration Sessions & The Value of Experiential Learning

I’ll be at STAR East Monday, May 4 through May 7 2009. Lots of other colleagues will be there too, including James Bach, Jonathan Kohl, Rob Sabourin, Karen Johnson, and James Lyndsay. I’ll be presenting a keynote talk, “What Haven’t You Noticed Lately: Building Awareness in Testers” (the title there was cheerfully lifted by me from Mark Federman, who cheerfully lifted it from Terence Gordon, who either lifted or channeled it from Marshall McLuhan, whom Federman explains cogently); an experiential tutorial called “Tester’s Clinic: Dealing with Tough Questions and Testing Myths“; and an experiential session called “Insource or Outsource Testing: Understanding Your Context“.

At every conference, big or small, I’m now offering coaching and collaboration sessions, based on an idea by (and often in cahoots with) James Bach. They’re free, of course; the whole purpose of a conference is conferring (about which more in the next post). Here’s how they work: I (or if James is around, we) announce that we’re going to be in the hotel lobby bar from 7:30 in the morning, after the regular daytime conference sessions, or any time you’d like to arrange; we bring along a bunch of testing toys, games, and puzzles, some on laptops and some not; and we work on them, engaging in exploratory play, conversation, coaching, critique of the exercises, and maybe exploratory testing of the bar’s beer list, for as long as people care to stay. In the fall, at STAR West, some of these sessions went on until 10:00pm before the toys were put away.

At these sessions, everyone learns something. The games and experiential exercises either come from the Rapid Software Testing course or are candidates for it. We already have a set of ideas as to how the puzzles might be relevant, but invariably the people that we’re working with discover new angles and give us new epiphanies as to what people can get out of the exercises.

Last week at the QUEST conference in Chicago was a great example of this kind of experience. Xavier Bignon, who attended my one-day exploratory testing workshop, is one of those testers who cannot resist talking about testing, thinking about testing, and solving testing problems. We arranged to meet in the hotel bar on Tuesday evening, after the official end of the conference day. This wasn’t an exercise I expected to do; on a whim, I pulled out a deck of cards, showed him a magic trick and asked him to reverse-engineer it. I am not a very good magician, so doing handing him this problem was the equivalent of giving him a program that has lots of interesting bugs and discoverable problems. I watched and coached him as he wrestled with each stage of the exercise. At one point, Xavier posited an explanation as to how I was getting something done; he reckoned that I was memorizing something about the cards, when actually I was performing a quick calculation—a much simpler approach. And that led me to discover a general systems law.

The Eye-Brain Law, (as far as I know identified by Jerry Weinberg in Quality Software Management Vol. 2, First-Order Measurement) says that to a certain extent, mental power can compensate for observational weakness. The Brain-Eye Law (ibid.) says that to a certain extent, observational power can compensate for mental weakness. I’d known about those ones, which provided support for my epiphany. What Xavier’s analysis made clear to me were these two:

The Memory-Brain Law says that, to a certain extent, memorization can provide a cheap and effective substitute for calculation. Memorizing your times table allows you to get the answer 56 far faster than adding eight plus eight plus eight plus eight plus eight plus eight plus eight.

The Brain-Memory Law says that, to a certain extent, calculation can provide a cheap and effective substitute for memorization. Calculating 50 x 50 as equal to 5 times five and add two zeroes is a lot faster than memorizing your times table up to 50.

If, in a computer program, you can look up a value in a table, that might be faster than calculating it (in fact, a problem with such a table was the basis for the Pentium bug). Similarly, if you can compute a value quickly, that saves immense time and space over looking it up. The skill in any kind of optimization is to figure out what things to trade, and how to trade them.

Now, it’s not like I discovered any of this stuff for the first time, for all humanity; programmers have known about these complementary principles forever. They’re two of the founding principles behind many forms of optimization. Matter of fact, people knew about the Memory-Brain Law long before there were computers; it’s the idea behind logarithm tables.

But then it struck me that it’s also one of the principles behind Rapid Testing itself: learning (ideally memorizing) a handful of lists of guideword heuristics, combined with skill developed through practice, allows testers to respond instantly and expertly to any testing situation. I’d known that intellectually, but chatting about it with Xavier helped me to realize on a deeper level that James and I are in the business of trying to optimize testing and the work that testers do.

Those are the sorts of lessons that experiential learning helps to teach, and that’s why we rely on it so heavily in the Rapid Testing course.

For his part, Xavier wrote to me: “I’m really excited about what I’ve learned with you. If there is a possibility to join a work group or something like that to be involved with your research and/or teaching, I’d love to know more about it.” You’re welcome any time, Xavier, and I will keep in touch. And everyone else is welcome too.

So… ping me (stareast@developsense.com) any time, and we’ll have fun together at STAR East!