Re: Users' documentaion and QA Teams

[Sean Wheller <seanwhe -at- yahoo -dot- com>]

--- Mariana Prusorova <mprusorova -at- hotmail -dot- com> wrote:
> 
> 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.
> 

Mariana,

Try to see Quality Assurance as a responsibility that
is shared by everyone in the organization.

Assuming that you are not a Subject Matter Expert
(SME), may I recommend the following.

Broaden the review process to include a wide spectrum
of people. Consider including SME's from the following
departments: Engineering, R&D, QA, Support, Sales and
Marketing.

Each should provide input from their perspective
during the review stages, so state your expectations
clearly to each member.

The sign-off should be last in the cycle and, if
possible, executed by the manager or department head.
The sign-off is an acknowledgment by the company that
the content provided is complete and accurate. That
the company is satisfied to the extent that it deems
the content acceptable for consumption by the
customer. Make this fact known to all concerned.

If the reviewers, who are considered SME's, have not
brought to your attention a technical oversight of
which you have no knowledge, then the problem is not
with you. To absolve yourself, try to implement
systems that have some type of blame annotation
attached. Just in-case everyone points the finger at
you.

When you receive back comments, implement them and if
required meet the person to clarify items. This type
of meeting often reveals issues that were ignored in
comments and other communications such as email. It
also builds relationship. When you move to the next
review, attach questions on matters outstanding and of
concern.

If you have done this and still technical matters are
not addressed, then chances are that 95% of your
customers will not notice the problem.

During review, don't be offended if people spot
spelling and grammar mistakes. Note the problem, thank
them and move on to the technical matters. There is no
point in being upset. Just keep the system. One day,
when matters get hot and people point the finger, just
refer to it in a calm manner. I can virtually
guarantee that the problem will be solved.

Try to keep a balanced view. Just think of
documentation in the same light as building software.
Software has bugs and so does documentation. Try to
catch and patch the bugs. If your company has a bug
tracking systems, ask the developers to log bugs about
the documentation. Then all you need is to patch them
and close the bug.

Most of all, have fun. There's no point if you don't
enjoy it.

--
Sean Wheller

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/