Re: Testing to Ensure Accuracy of Information

[Glen Accardo <glen -at- SOFTINT -dot- COM>]

>                                                    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?

If I never saw it, it doesn't exist.  Period.  Since I write configuration
guides for our software, testing something often involves a considerable
amount of time.  That is, two or three sentences could take half a day to
verify.  To avoid duplicating everyone's work, I go by a few rules.

1.  If only a developer did it, it's pure fantasy.  I'll test it myself.

2.  If someone in tech support did it, he's probably willing to bet his
    life on it, or at least tell it directly to a customer.  I'll write
    this information and get them to verify it.  So far, this has been
    my absolute most reliable source of correct, concise information.

3.  If it's in the source code, I'll document it, but I'll let tech support
    know that it's kinda iffy. (Sometime necessary for obscure error messages
    and the like.)

4.  In other situations, I document what I see, regardless of the specs.
    Sometimes this is a rude awakening for developers.  (See rule number 1.)

I've tried being really hard-nosed about the facts in MY manuals.  If I
haven't verified them, I claim that the manual is defective and I won't send
it to the printer.  Of course, in getting developers, etc. to verify it,
they sometimes rush it out the door without real proof reading (more like
proof-looking-at-it) and there is, alas, nothing I can do about that -- yet.

------------
glen accardo                         glen -at- softint -dot- com
Software Interfaces, Inc.            (713) 492-0707 x122
Houston, TX 77084

Did the Corinthians ever write back?