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.
I think this is the most important thing to happen in testing documentation,
and has nothing to do with usability. You are verifying that your
documentation and the software match one another.
I have usually done this sort of "testing" as I write and only do it again
at the end to find out if anything in the software has been changed since I
last tested. This works well if development is closing one or more features
at a time and not waiting until the end of the process to close features and
integrate the software.
If development is waiting until the end, or not giving you the software,
then I think you can legitimately argue for at least 1-2 hours per
page/topic to verify all of your procedures.
We generally have someone other than the writer do this testing, since
writers of all types are so close to their product they often do not see
errors.
Of course, your management could reject the request of this testing time and
opt to ship your documentation without having this verification done.
If they do, I would get it in writing that the docs have not been verified
against the final software, and maybe even argue to include something in the
docs telling the user that there is no guarantee the docs and software will
match.
-----Original Message-----
From: Keith Allingham [mailto:kallingham -at- PLAINTREE -dot- COM]
Sent: Tuesday, June 29, 1999 12:48 PM
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Subject: Re: Time Estimation Question
I have to disagrwith this.
I would *like* to agree (that would make my job way easier).
However, this is verification - its an integral part of the
documentation production process.
Sizing it can be iffy, I agree, but your estimate can include cya's
like "each procedure will take 1.5 hours to verify, assuming
functional s/w"
- if the s/w is not functional, you can't take the
blame for a schedule overrun
- if the s/w has changed, ditto.
Its all about CYAs and negotiation.
My 2 cents,
Keith Allingham
Plaintree Systems
______________________________ Reply Separator
_________________________________
Subject: Re: Time Estimation Question
Author: Donald Le Vie <dlevie -at- VLINE -dot- NET> at internet
Date: 6/29/99 1:33 PM
I would provide an estimate on all other services BUT the one you're having
trouble with. That's more of a usability issue than an editing issue.
Different set of requirements....
Donn Le Vie
Director, Information Development
Integrated Concepts, Inc.
> -----Original Message-----
> From: Letty Smith [SMTP:lsmith -at- CTILIMITED -dot- COM]
> Sent: Tuesday, June 29, 1999 1:10 PM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Time Estimation Question
>
> I have searched the archives and wasn't able to come up with a good answer
> to this question. Hopefully, some of you out there have faced a similar
> situation and can give me some advice.
>
> I am working on editing a set of online help documents for a software
> product. The editing is a comprehensive one, designed to:
> Fix grammar errors
> Improve the clarity
> Spell check
> Reformat long documents into managable sections
> Include screen prints of processes and buttons
> Provide consistent naming conventions
> Check that each field on the software matches the documentation
> Run each process that the software can do, and make sure that the
> software actually does it the way that the documentation says it
> does.
>
> The last item is the one that is stumping me. This is very complicated
> software, and running any one of the processes takes somewhere between 1
> minute and 3 hours (depending on how much previous data I have to load and
> create for testing). I have had tests take a whole day to finish, when
> the
> system was feeling buggy. They have also taken 20 seconds.
>
> Does anyone have a good rule of thumb as to how to estimate how long this
> sort of editing should take? I'd like to be able to present my manager
> with some guesstimation, as I'm starting to get the "gee, what are you
> DOING with your time" looks. Currently, there is no method being used to
> estimate how long it should take, so any help would be an improvement.
>
> How about for this sort of edit *without* the software testing?
>
> Letty Smith
>
>
> From ??? -at- ??? Sun Jan 00 00:00:00 0000=
> =
>