STC Usability SIG Newsletter
Usability Interface

Justification for Documentation Testing

by David Dick

Is documentation testing a part of your production process? If not, don’t you think that it should be? Generally, Technical Writers work to tight schedules, which often does not include documentation testing because there is no time. Besides, who wants to take the risk of causing a rewrite or correcting product design and not shipping on schedule? Nobody! What is needed is a justification for including documentation testing in the production schedule.

In "Liability for Defective Documentation," Cem Kaner provides valuable justification for documentation testing to ensure quality. Bad documentation, he says, has a ripple effect on the number of users it impacts such as Product Development, Training, and Customer Support.

Effect of Quality Documentation on Product Development

• The manual provides an overview of the program. Despite best efforts by Quality Assurance to evaluate the program, a thorough test of the manual against the program is likely to highlight problems that were overlooked.
• New programmers and testers who join the project can use the manual to learn the program..
• Many product development groups stop maintaining the external specification and rely on the manual to serve this purpose.

Effect of Quality Documentation on Training

• Customers will need less training and can proceed more quickly to advanced training if the manual is high quality.
• If the Training department likes and trusts the manual, it will use it for training purposes, saving the company time and money.
• If the manual is of high quality, the Trainer can use it to reinforce tips and tricks during the session. This can give a real "piece of mind" boost to the company.

Effect of Quality Documentation on Customer Support

• It takes less time and costs less to prepare answer books – A well-organized Support staff prepares books or a database of answers to the questions that they expect will be frequently asked, or that will be difficult to answer.
• It makes calls take less time – Sometimes the best way to handle a call is to alert the customer to the relevant section of the manual.
• It results in less difficult calls – There’s nothing Support staff like less than dealing with customers that were misled by the contents of the manual. Imagine dealing with a person who has followed the instructions but wasn't able to achieve the result that the manual promised, or worse, who followed the instructions but lost data or got into trouble. Such calls can discourage Support staff.

Every Technical Writer has experienced resistance to doing what is necessary to thoroughly test manuals. To people who care about quality, you are talking about customer satisfaction. To people who care about schedules, you are talking about efficiency because a well-tested manual helps to train Development and Support staff faster. To people who care about saving money, you are spending a little to save a lot. To people who are afraid of making decisions, you are providing a business case that makes this decision look safe and obvious.

References

Cady, Dorothy L. 1953. Bulletproof Documentation - Creating Quality Through Testing.

Kaner, Cem. 1995. Liability for Defective Documentation (Software QA, Volume 2, #3, 1995, p. 8) also available at http://badsoftware.com/baddocs.htm