TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:RE: Users' documentation and QA Teams From:<Daniel_Hall -at- trendmicro -dot- com> To:<mprusorova -at- hotmail -dot- com>, <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 23 Jan 2004 08:29:06 -0800
Some thoughts:
As with any review process, a key factor is letting your reviewers know what you expect from them, and then providing feedback when they have given you their comments.
At my current employer, the QA team has been extremely cooperative in reviewing the content of the documentation and catching instances where the doc doesn't exactly match the operation of the product or where there's a detail missing. In general, I work with the QA lead, who distributes the documentation in sections to her people for review. When I get their feedback, I am always careful to respond with a quick thank you. In my response, I also ask for clarification on anything that's still not clear. In addition, I always make a lot of appreciative noise about the "technical" comments, and pretty much completely ignore the other comments (not that I don't incorporate those changes when appropriate, I just don't provide positive feedback for those items.) This happens both in my weekly reports and the team meetings. So far this method has been successful in encouraging more "technical" and less "editorial" feedback.
My first suggestion is to make sure that you have clearly stated what you expect from them, and then try and positively reinforce "good" behavior. If this fails, you may need to take it up with the senior QA person or up the chain of command.
Be sure that you stress that the best return on the investment of QA time is technical review (what you're calling "usability"). Whatever you do, try not to say that you "don't want" their feedback on grammar/spelling/formatting/whatever. For one thing, this input is valuable. Every set of eyes that looks at a document improves the chances that errors will be caught. As Andrew indicated in an earlier post, some engineers and QA folks can write pretty well - their input can only make the documentation better. This is important, because for most readers, spelling or grammar errors and formatting inconsistency detract from the "ethos" of a document and have a negative impact on your corporate image.
Dan
-----Original Message-----
From: bounce-techwr-l-129804 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-129804 -at- lists -dot- raycomm -dot- com]On Behalf Of Mariana
Prusorova
Sent: Thursday, January 22, 2004 3:37 AM
To: TECHWR-L
Subject: Users' documentaion and QA Teams
Hi, Please share some of your experiences with the QA teams, how do you
communicate with them and what is your process . Do you ceate special
testing plans - how the user documentation should be tested?
I think they should test more the usability - whether the needed
information is provided to the user and questions are answered.
By us the situation is that they test my design, alignment, grammar,
anything but the conntent, mostly the form. And fixing bugs about minor html
details waists my precious time, when I could develop more/better content.
Further more the tests are continuouing even when the new release is
already a fact; and commas, spaces etc. have to be patched on the
lifesystem.
