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.
> My company is considering a more formal approach to validating the
software
> sections of our operator manuals by developing a more intimate
alliance with
> our internal software QA department. Specifically, we are
considering
> asking software QA to validate the operator manual at the same time
as
> software builds are tested.
> I have some questions - Any ideas on how such a relationship can
best work
> for all parties involved? Is this a natural alliance (i.e. should
> techwriters of software be closely linked with SQA)?
I did something similar as a lone tech writer on a project (well, I
wasn't exactly "alone," per se; my supervisor was just awfully busy on
another project). I was documenting a product I had never seen -- let
alone used -- before, so I had to bounce the new version of this
program against what was in the old (and universally despised, by the
way) manual, which I was rewriting.
Long story short, I found several bugs while trying to figure out how
to use the program -- even after it had been through QA a couple of
times.
I used the senior-most tester there to test parts of the manual (the
new tutorial section); she usually gave me good feedback, though at
times, she was just too swamped to do so. Here, your idea of a more
formal relationship between the two departments would be ideal -- and
eliminate (well, sort of) the problem of too-busy testers.
In an attempt to answer one of your questions: Yes, by all means try
to integrate the two departments. If you could slip a techwriter into
the QA department somehow, that could help immensely with UI issues
("No, no, NO! 'End' does not belong under the Edit menu!"*).
There may be some bruised egos, though ... but that is something that
is hard to avoid. Should your techwriter/QA integration idea work
well, those bruised egos will go away.
Eventually.
> Thanks for the input.
Might be late due to my Digest mode, but ... what the heck. Hope it's
of some use ...
--gdw
___________
*No, I didn't actually have this discussion; I just pointed out to the
new programmer as one of the UI issues that should be fixed in the
next version.
> -Malkia
"Well, you know what they say: the bigger they are --"
"-- the faster they stomp you into nothing."
--Xander and Willow discuss stategy before battling Glory
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
