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: Testing to Ensure Accuracy of Inform From:Mikael Orbratt <Orbratt -at- ERITEL -dot- SE> Date:Sat, 30 Jul 1994 22:00:00 +1
I agree on that it is my responsibility as a thechnical writer to make sure
that what I write is true However, to a certain degree of detail you can't
confirm the facts only by testing. You need support from thoso who are
responsible for the functionality of the products, the constructors.
At our company have made the constructors responsible for the facts in the
documentation. The technical writers are responsible for the documentation
as a whole and of course for layout, language etc, etc. We have the
constructors reading all the documentation that we produce, which have made
them really interested in the documentation delivered with our products. The
documentation covers both hardware and software. The constructor often comes
up with ideas about what and how to write, to make the documentation better.
We have problems to get enough time for testing the documentation. We have a
dead-line common to both the products and the documentation, which is very
tight. As usual, it is the time for the documentation that is cut off when
time schedules and budgets are tight. The only way I see to have the
documentation really tested, is to do afterwards and make changes needed, to
the next release.
Another question that I'm interested in is how much time that is spent on
prestudies before starting to write. Which information do we have to
include? What does the reader want/expect to find in the manuals? How do the
reader want the documentation structured? etc, etc..... How do we as
technical writers know that the time we spend on writing gives the reader as
much as possible for the money he/she pays?
orbratt -at- eritel -dot- se
---------- Original message
I'm curious as to how many of you verify what you write by testing the
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
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
well, but I've often found that the information I get from both sources can
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.
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
their fault and not yours? I try to test everything I can while still
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
issue of whether I've failed to uphold the ethics of my profession.