personal style while maintaining the written "image" of the group. Of course, the quality of the writing that "fills in" the outline must be high, or else the image is quickly undermined. Just because different team members' writing looks the same doesn't necessarily mean that it's written well.
Many testers I have met share the feeling that they are seen as less-than-equals by the development teams they work with. Quality writing is a trait that all professionals seem to appreciate, particularly when the document must stand on its own without the author present to back it up. An author must be confident in and knowledgeable of a topic to write well about it. Quality documentation tells developers and management that the author is a professional, which elevates their perception of the author and of the whole test team.
Pitfalls that Come with Writing
At this point (if you're still reading), you probably think I'm under the impression that writing can solve all the problems testers face on a daily basis. While I do believe that there are a number of things that good writing skills can help resolve or remedy, there are just as many potentially negative effects of writing and written documents. In order to achieve the benefits listed above, it's important to keep possible pitfalls in mind.
I've mentioned templates and document "shells" as potential benefits to a test team. I firmly believe that having a good starting point to work from when writing can significantly reduce the amount of time needed to complete a document and can help the less-experienced writers on your team learn from those with more practice. However, it is easy to be lazy when using a template or sample document. Many people simply copy and paste wording into their new work-template document, even if it is not precisely applicable to the current project.
Another shortcut that can damage the quality of your writing is the assumption that a reader will know or understand what you're trying to say and that you can therefore take shortcuts or omit information. Always assume that the reader will not understand you unless you spell out all of the pertinent details. There's no need to talk down to your audience, but you shouldn't expect them to be able to read your mind, either. Both taking shortcuts and reusing inapplicable sections of text are symptoms of lazy writing. Lazy writing is often a reflection of lazy thinking, and no professional tester can afford to be a lazy thinker, or be seen as a lazy thinker.
The perception that the author of a document is an expert on the subject can help the test team gain equal footing with their development counterparts. However, as a writer, you must always make sure that your writing deserves the "expert" designation. One incorrect expected result or mistaken step in a test case can quickly change someone's opinion both of your work and of you, personally. It's often difficult to build a solid reputation as a professional within the testing field, but it's much more difficult to rebuild that reputation.
One pitfall particularly applicable to test team managers is the assumption that all members of the team are at the same level concerning their writing skills. Remember that each person thinks, and therefore writes, differently. It's important that each member of your team be capable of quality writing when necessary. To help achieve that goal, be sure to take into account the scope and nature of the job when assigning a writing task to a member of your team. Then assign the project to