Peer Conferences and Learning

In the past two years, “Peer conference” and “exhibition conference” are terms I’ve come to use a lot. A peer conference is a get together among practitioners of a particular discipline for the purpose of learning to practice better. It’s a round table, sometimes literally. An exhibition conference is what most people call just conference. There is often not much conferring going on at an exhibition conference. The point of most such “conferences” is for one class of people to put on a show for another class of people.

At an exhibition conference, it is considered impolite for someone to stand up and criticize the ideas of a speaker. It would be as if someone tried to talk back to the screen at a movie theatre. For many people attending exhibition conferences, there is a presumption that the speakers are experts. Thou Shalt Not Doubt Experts.

At a peer conference, everyone is a speaker, and it is expected that we will criticize each others’ ideas. We’re after deep learning, and it’s hard to get that without getting behind the Powerpoint glitz.

In my community, we’ve held sixty or seventy of these meetings since the first one in 1997 (the Los Altos Workshop on Software Testing, organized by Cem Kaner and Brian Lawrence). It’s become a vital mechanism for building relationships and developing our craft. It’s getting a little crazy, actually. In the last three weeks I’ve been to three peer conferences: The Workshop on Combinatorial Testing (WOCT), The Exploratory Testing Research Summit (ExTRS), and the Workshop on Training Software Testers (WTST).

Peer conferences create an environment for cross-organizational learning.

Recently, I’ve noticed a shift in the culture of the meetings. I’ve started using them as opportunities to challenge my colleagues to “testing duels” of various forms. Some of my colleagues have followed suit, so that when we meet, I can expect to be barraged by brainteasers or exhortations to test this or that with one or more hands tied behind n-squared backs. As a result, I get terribly sleep-deprived. It’s wonderful.

This is important if we want to build a better craft. For instance, I don’t think that the Agile community understands testing, yet. Testing is a skill of the mind, not a software tool that glows red or green with news of the trivial. I think the community of genuine software testers (those who devote themselves to the study and practice of dispelling illusions about software products) has a better hope of helping the Agile programmers understand what we do if we pose testing problems to each other. We should show those guys that not just anyone who falls off the backend of a compiler can expect to test with the big dogs.

I dream of a testing craft where bright young testers study hard to distinguish themselves at the next local testing tournament, the state championship, or the nationals.