Bulletproof Documentation: Creating Quality Through Testing
Book Review in Technical Communication | May 01, 1997 | Eldard, John P.
Dorothy Cady's Bulletproof Documentation is not just a book about documentation testing, but a complete primer on documentation quality testing for the technical communicator. Cady discusses the complete product development cycle and the documentation development process before going on to the document tester's role. She then provides the details for setting up documentation testing in your company. In my library, Bulletproof Documentation belongs on the bookshelf next to works by JoAnn Hackos, Bill Horton, and other important writers about our profession.
This book is easy to read, with plenty of meaningful subheadings, chapter summaries, and end-of-chapter references. Although some of the graphics seem unnecessary to understanding the principles discussed, they provide necessary white space to ease eye strain.
Cady introduces her readers to the documentation testing process in Chapter 1, "An Introduction to Documentation Testing." The five common levels of documentation tests that she explains are
* Read-through. The read-through is simply a reading of the document to be tested. The primary purpose of this kind of test is to ensure that all the facts are stated correctly and all relevant information is included. The most common type is the peer review.
* Engineering review. An engineering review is a read-through conducted by a product engineer rather than a documentation tester. The difference is that the engineer has access to other engineers and a greater depth and breadth of test and laboratory equipment than the documentation tester.
* Usability. A usability test is often conducted on the product as well as on the product's documentation. It is aimed at determining what aspects of the product's interface are particularly useful or particularly difficult for the intended user. Often, it is designed to find and correct areas of the document that discuss aspects of the product with which the product's designers and developers are not totally comfortable.
* Basic functionality. The basic functionality test assesses the accuracy of a procedural or task-oriented document. It also looks at ease of use.
* Integration. When performing an integration test, the documentation tester attempts to take into consideration every environment or situation in which the document and product could be used, and tests the document accordingly.
The information included in this book is not just a compilation of Cady's ideas about documentation testing; ideas and examples from other authors are well-referenced throughout. Want to know more? Look up the sources in the References section at the end of each chapter.
Cady provides a good discussion of the marketing requirements document and the product design requirements, as well as other specifications used when writing documentation. Document plans, reviews, and edits are included. By the time Cady goes through the basics early in the book, the reader is well-prepared for the meat of the documentation tester's duties.
Chapters 2 and 3 are dedicated to "Documentation Testing and the Development Process" and "Preparing for a Documentation Test," respectively. For readers new to the documentation testing process, Cady provides guidelines for estimating testing time requirements, something that takes a lot of time and experience to do successfully.
Chapter 4, "Conducting Documentation Tests," includes a discussion of both electronic and paper documentation. All aspects of the documentation testing process are explained, including instructions on how to conduct each type of documentation test and examples. Cady assumes no prior knowledge, making this the primer that it is.
According to Cady, documentation testers need to set up an area other than their regular workspace in which to conduct tests. She writes,
People who walk past your cubicle or come to your office and see you sitting and reading will assume you are reading because you have nothing better to do. They might see this as a sign that they should stop and chat. Or worse yet, your boss might get the impression that you do not have enough work to do and see to it that the situation is corrected.
The author provides other good insights in this chapter. For example, a good documentation tester is careful to simply note a minor problem without "making a big fuss over it" because the editor gets the document at the same time. Also, it is not a documentation tester's job to write the document for the writer.
Chapter 5 is "Reporting and Following Up on Your Testing Results." Despite all the good examples, I think Cady gets a little too basic here. For instance, she provides a sample of an e-mailed product problem report.
Chapter 6, "Becoming a Documentation Tester," gives you a good idea of what is expected of a documentation tester. Responsibilities, personality traits, skills, and abilities are discussed.
Chapter 7 ("Starting a Documentation Testing Group in Your Company"), Chapter 8 ("Hiring a Documentation Test Team"), Chapter 9 ("Training and Motivating a Documentation Test Team"), and Chapter 10 ("Some Final Guidelines") are your tools for setting up and managing a process to produce bulletproof documentation in your company.
Whether you want to become a documentation tester, set up a testing group, or just learn more about what it takes to guarantee quality in your documentation, this book is for you.
John P. Eldard Publications Manager Park City Group Orem, UT
Eldard, John P.. "Bulletproof Documentation: Creating Quality Through Testing." Technical Communication. 1997. Retrieved September 30, 2009 from accessmylibrary: http://www.accessmylibrary.com/article-1G1-20221515/bulletproof-documentation-creating-quality.html.