Re: The Documentation Being Put Through Qual Assistance Process

[Beth Agnew <beth -dot- agnew -at- senecac -dot- on -dot- ca>]

Agnes, this is not necessarily a bad thing. I have not seen this process 
work exactly the way you describe it, but there are many good reasons 
for QA and documentation being together. It will feel strange to you 
until you go through the cycle a few times. Sounds like you're having to 
undergo quite a paradigm shift.

Perhaps the easiest way to attack it is to remember that documentation 
always has been iterative. We do a draft, then we look at it to find 
errors (bugs), and then we fix those errors and issue another draft 
(build). The document development life cycle is the same as the software 
development life cycle. (Which is also the product development life 
cycle as well as the project life cycle.) The more you can see the 
parallels between QA for documentation and QA for product, the easier 
this transition will be for you.

I have worked in companies where we created bug tickets for 
documentation errors as well as product bugs. You can apply the same bug 
priorities and methodology to errors in documentation as you can with 
software. Ask yourself how it would be handled for software, and then 
how should I adapt this for documentation. You probably wouldn't have a 
bug ticket for each typo, but you'd have one that said "Needs a spell 
check and pass for typos". Since you have online documentation, it is 
quite reasonable to have QA test it all to make sure the links work, etc.

The QA people assigned to you, however, need to include your SME, a 
technical editor, and anyone else capable of proper documentation 
reviews. Just as one would review software specifications and design to 
make sure the right thing is being built, draft documentation has to be 
reviewed by the SMEs so you know that what is going online is correct. 
Good QA for software includes user testing, not just automated test cases.

I think you will find this process to be quite enjoyable when you see 
how strongly the documentation and software cycles mirror each other. 
Once you learn the nuances of the software development life cycle, you 
will be able to work the methodology to your advantage with the 
documentation. Many techwriters have managers who do not understand 
documentation, so you are not alone there. It will be your job to ask 
for what you want, justify it in terms they can understand, and then 
help them adapt the process so that you are fairly treated. Educate your 
"client" about your job, and work with whatever system they give you. 
You can indeed succeed at this, and it will open up future doors for you 
because of your increased experience.
--Beth

Agnes Starr wrote: