A lot of people I teach seem to be under pressure to create more documents to describe their test process. But documenting is not testing. It is one of the chief distractions to testing.

“James Bach hates documentation!”, some people will say. No, I don’t. I hate waste. I hate boring clerical work that unnecessarily interrupts productive and interesting intellectual work. You should hate it too.

I’m a writer for cryin’ out loud. I like documentation– when it is the solution to a problem that matters, and not merely a management obsession. But if you’re trying to move to concise test documents (outlines, matrices, one-page reference sheets, and other minimalist formats) you may need help persuading management and co-workers.

Here are some ideas:

• Show management how much less testing we are able to do because we are spending so much time with documents.
• Show management how certain kinds of testing isn’t done at all just because it is hard to document (exploratory testing and complex scenario tests often fall in this category). This is perhaps the most chilling effect of over-documentation, especially in the realm of medical devices. I keep seeing medical device test doc that is simplistic, in all its obesity, to the point of near worthlessness.
• Examine closely what testers are doing and show that they aren’t even following the documentation (often they aren’t, in my experience as a consultant who audits test processes).
• Demonstrate the power of exploratory testing (a less heavily documented approach). One day of ET is often sufficient to find what would take a week to find when following detailed documented test procedures.
• Demonstrate the value of concise test documentation (matrices, outlines).
• Consider documenting at the level of test activities rather than test cases.
• Consider automatic documentation (via log files produced by the product under test or via an external logging tool such as Spector).
• Ask the question: what exactly are we getting from our documentation? Don’t accept any theoretical answers. For example, one typical answer is that documentation protects the company from the ill effects of staff turnover. But does it? Probably not, in my experience. That’s a theory based on ignorance about how people learn. In real life, new testers learn what they need to know by playing with the product itself, and talking to the people around them. In my experience, testers come up to speed in a few days at most. And in my experience, test documentation is often of such poor quality that it’s better ignored than followed. You have to go by your own experience, of course. I’m just suggesting that you ask the questions and make your own observations.

Here are a few books about documentation that might help you make your case:

• Follow the Yellow Brick Road
• The Social Life of Information
• Things that Make us Smart

Heavy documentation is often a consequence of managers and testers who just aren’t thinking through the reasons why they do things. They hear that documentation is good, but they don’t stop to consider the cost of documentation, or watch how documentation is actually used (or more often, ignored).