Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Sun, 03 Oct 2004

My testing metaphor

I don't think I have a firm grasp of XP's metaphor. Nevertheless, I am taken with the idea of using a guiding metaphor to encourage cohesive action. So what about a guiding metaphor for testing in Agile projects?

The picture on the right is my idea of conventional testing's dominant metaphor. The tester stands as a judge of the product. She acts by tossing darts at it. Those that stick find bugs. The revealing of bugs might cause good things to happen: bugs fixed, buggy releases delayed, a project manager who sleeps soundly at night because she's confident that the product is solid.

When talking to testers, two themes that often come up are independence and critical thinking. Critical thinking, I think, means healthy skepticism married to techniques for exercising it. Independence is needed to protect the tester from being infected with group think or being unduly pressured. A fair witness must be uninvolved to get at the truth.

There's no question in my mind that human projects often need people governed by this metaphor. But what about one type: Agile projects? Some say conventional testing exists, it's understood, and Agile projects need to import that knowledge.

I agree. We need the knowledge. But maybe not the metaphor and the attitudes that go with it. Independence and - to some extent - error-seeking are not a natural fit for Agile projects, which thrive on close teamwork and trust. Is there an alternate metaphor that we can build upon? One that works with trust and close teamwork, rather than independently of them? Can we minimize the need for the independent and critical judge?

I think so. Other fields have ways of harnessing critical thinking to trust and teamwork.

• Latour and Woolgar describe scientific researchers as paper-writing teams (Laboratory Life). As the paper goes through drafts, coworkers critique it. But the critiques are of a special sort. They are often couched as defenses against later attack: "Griswold is obsessive about prions. If you leave this part of the argument like it is, he's going to go after it." They often include trades of assistance: "The last JSTVR reported a new assay. You need to run that, else you'll be dated right out of the gate. I can loan you my technician."

  My wife, who is a scientist, confirms this style. In her team, certain people have semi-specialties - one professor is good at statistics, so he wields SAS for other people, and I get the impression that my wife is strong at critiquing experimental design - but they all work together in defense of the growing work.

  I think it's interesting and suggestive that all of these people are producers. Despite being a referee for a seemingly infinite number of journals, my wife isn't just a critic. She's also a paper writer.

• Richard P. Gabriel describes writers' workshops in Writers' Workshops and the Work of Making Things. A writers' workshop is an intense, multi-day event in which a group of authors help each other by closely reading and jointly discussing each others' work. Note that, like the scientific papers, the work is not complete. The goal is to make it the best it can be before it's exposed to the gaze of outsiders. Trust is important in the workshop; there are explicit mechanisms to encourage it. For example, the group discusses what's strongest about the work before talking about what's wrong. And, again, everyone in the workshop is a producer (at least in the traditional workshops, though not necessarily as they've been imported into the software patterns community).

So, with those examples in mind, I offer this picture of an Agile team. They - programmers, testers, business experts - are in the business of protecting and nurturing the growing work until it's ready to face the world. (To symbolize that, I placed a book in the center, which is where herd animals like elephants, bison, and musk oxen place their young when danger threatens.)

Notice that the dinosaurs are all of the same species. Even though some of them might have special skills (perhaps one of them knows SAS, or was once a tester), they are more alike than they're different. They're all involved in making the weak parts strong and the strong parts stronger. (The latter is important: it's not enough to seek error; one must also preserve and amplify success, and spread understanding of how it was achieved throughout the team.)

P.S. Malcolm Gladwell wrote an interesting discussion of the virtues of group think.

Illustrations licensed from clipart.com.

## Posted at 23:22 in category /agile [permalink] [top]