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:Testing to Ensure Accuracy of Information From:"Documentation is part of the product." <angela -at- SATURN -dot- SMARTSTAR -dot- COM> Date:Fri, 29 Jul 1994 16:27:54 -0700
I'm curious as to how many of you verify what you write by testing the product
you're writing about. I would guess that the answer to this is affected by
where you get your information. If you get it by using the product, then this
is a mute point. If you get it from product specifications or by talking to
the developers themselves, do you test everything you read or hear by using the
product to make sure that what you write is accurate?
Where I work, we get information from specifications, but they aren't always
complete or kept up-to-date. So, I ask lots of questions of the developers as
well, but I've often found that the information I get from both sources can be
incomplete or inaccurate. So, I try to test everything I write, because I feel
it is my responsibility to make sure that what I write is true. However, this
can be very time-consuming, and I can't do it all the time if I want to meet
the deadlines set for me. I often wonder whether or not those "average # of
pages produced per day" formulas for technical writing projects take testing
How do you resolve this dilemma in your situations? Do you feel it's your
responsibility to test everything, or do you feel it's not your job to check
up on everything you're told -- that if someone gave you wrong information it's
their fault and not yours? I try to test everything I can while still meeting
deadlines, but I always feel uneasy sending something out that I haven't
verified, because I know it'll come back to me as a documentation bug,
regardless of whether I got it from a spec that was wrong. Also, there's the
issue of whether I've failed to uphold the ethics of my profession.