Over at the Agile-Testing list, there's another outbreak of a popular question: are testers needed on Agile projects? To weary oldtimers, that debate is something like the flu: perennial, sneakily different each time it appears so that you can't resolve it once and be done with it, something you just have to live with.

After skimming the latest set of messages on the topic, I returned to editing a magazine article and then I had a thought that might just possibly add something.

Editors are supposed to represent readers (and others), just as testers are supposed to represent users (and others). To an even greater extent than testers, editors do exactly what the the represented people do: they read the article. And yet, you can't take J. Random Reader and expect her to be a good editor. Why not?

It seems to me that as readers we're trained to make allowances for writers. We're so good at tolerating weak reasoning, shaky construction, and muddled language that a given reader will notice only a fraction of the problems in a manuscript. A good editor will notice most of them. How?

Some of it is what "do we need testers?" discussions obsessively circle: perspective. Editors didn't write the manuscript (usually...), so their view of what it says is not as clouded by knowledge of what it should have said. Editors also do not have their ego involved in the product.

But that perspective is shared by any old reader. What makes editors special is, first, technique. I put those techniques into two rough categories:

• Model-building techniques. Esther Derby has described cutting a manuscript into pieces and rearranging them on the floor into something like an affinity map. She created a content model she could use to explore structure. In testing, James Bach and Michael Bolton teach many model-building techniques under the umbrella name Rapid Testing. Programmers who learned from them would do better (modulo perspective effects).

• Something I don't know how to name. Call them attentiveness techniques. It sometimes happens that I have a niggling feeling of something wrong with an article. It's easy to ignore those. But if you have techniques to explore them, you're more likely to. For example, sometimes I find it useful to use the literary technique of deconstruction to figure out an article's implicit assumptions or contradictions.

  It seems to me the exploratory testing world would be the place to look for something that could be adapted to programmers. I'm somewhat disconnected from the leading edge of that world these days, so I don't know how explictly this topic has been taken up. (If you're looking for something to read, Mike Kelly has quite a list of books that have influenced exploratory testers.)

But there's something else that editors and testers have that programmers don't have: leisure. When I'm acting as a pure reader, I intend to get through it and out the other side quickly. As an editor, there's no guilt if I linger. There's guilt if I don't. One problem that Agile projects have is a lack of slack time, down time, bench time. There's velocity to maintain—improve—and the end of the iteration looms. Agile projects are learning projects, true, but the learning is in the context of producing small chunks of business value. There's no leisure for the focus to drift from that. (I'm using "leisure" rather than "permission" because so much of the pressure is self-generated.)

My hunch is that perspective is less important than technique and leisure for producing good products. If the testing and programming roles are to move closer together (which I would like to see), the real wizards of testing technique need to collaborate with programmers to adapt the techniques to a programmer's life. (I tried to do that a few years ago. It was a disaster, cost me two friendships. Someone else's turn.) And projects need some way to introduce leisure. (Gold cards?)