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?

a dartboard with labeled darts 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).

a circle of dinosaurs protecting a book 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]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo