Does Editing Ensure Quality?
	Often, when a group feels the need to define itself as a distinct profession, the members claim that they share the characteristics of a more established or more respected discipline. Here is a case in point. In the article, “Technical Editing as Quality Assurance: Adding Value to Content,” Michelle Corbin, Pat Moell, and Mike Boyd argue that technical editing is a form of quality assurance. Why? Because editing resembles software testing. The authors argue that “Just as software testing is a viable, separate field, so too should technical editing be a viable, separate field.” Separate from what? From writing, mostly. They argue, convincingly, that editing requires a different mindset from writing, and that halfway measures, such as writers editing their own work, or reviewing the work of peers, often fail. They champion the idea that technical editors should be seen as members of a distinct profession. But what kind of profession? The authors say that editing should be considered a way of improving quality in documentation. And they have lots of support for that position. Lori Fisher, for instance, has said, “Many characteristics of quality fall within the scope of editing.” The authors expand on that argument in great detail, organizing their description of technical editing in three levels that correspond to the activities of traditional validation testing.
Unit testing and function testing	Reviewing every word and every sentence for consistency of terminology, brevity, clarity, syntactic clues to the structure of sentences, and cross-cultural relevance     Ensuring standards through templates, stylesheets, prototypes, and styleguides     Verifying that each component is actually delivered.
Integration testing and system testing	Ensuring accuracy     Working on the big picture     Reducing the amount of information     Re-using information (single-sourcing)     Customizing information for different tools and groups     Working toward continuous improvement.
Usability testing	Checking indexes, tables of content, headings, and cross references to make sure that users can retrieve information successfully     Making sure that the text is accessible for all users     Adjusting style and content for the target audiences. This model of software testing is, of course, based on traditional project management, not user-centered design with its rapid prototyping and incremental or spiral processes. But the description of editing as a form of software testing applies even in an object-oriented or UCD environment, because the authors are not really describing phases, but types of activity. Whenever editors apply these skills, the work improves the quality of the final output, whether that is documents, topics, or content objects. Other methods help. Quality can be improved by building more accountability into the process of writing, reviewing, and usability testing. But in many circumstances, documentation does not get tested, reviewers are a bit casual, and the writers are sunk in a sea of minutia. Enter the editor, a professional stand-in for the audiences, applying an entire arsenal of standards, techniques, and heuristics to make the content     “Clearer, more concise, and more comprehensible”     Coherent     Visually organized     Efficient     Easy to access     More accurate and less ambiguous. In all these ways, then, editors add value to the documentation, making the content more usable, while driving down the cost of production, translation, and support. As “champions of our profession,” these authors hope that editors will argue that editing offers measurable value to the users and the organization. So if you are an editor hoping to convince management that your work deserves a raise, you can point to this article as evidence. And if you are a manager trying to justify adding an editor to your staff, you'll find many ideas that will make sense to a boss who is interested mainly in return on investment. Are the authors a bit idealistic? Yes. For instance, they assume that an editor will be able to check the documentation against accurate, up-to-date specs – a charming fantasy, I think. And some editors are so pressed for time, or so frazzled, that they do not carry out these tasks very well. But, in general, editors, like software testers, are a godsend to any group. As JoAnn Hackos has said, technical editing may be “the single most important quality assurance mechanism in the publications-development life cycle.” What do you think?
References	Corbin, Michelle, Pat Moell, and Mike Boyd. August, 2002. Technical editing as quality assurance: Adding value to content. Technical Communication, Volume 49, Number 3. Fisher, Lori. 2000. Defining and Developing Quality Information (Course notes). University of California Extension, Santa Cruz. Hackos, JoAnn T. 1994. Managing your documentation projects. New York, NY: John Wiley & Sons, Inc.
	About the Author: Jonathan Price, a senior member of the STC Kachina New Mexico Chapter, is also co-author with Henry Korman of How to Communicate Technical Information. With his wife Lisa, Jonathan recently published Hot Text: Web Writing that Works, available at www.webwritingthatworks.com. Back to top