FW: Formal document testing

[Richard Lippincott <richard -dot- lippincott -at- ae -dot- ge -dot- com>]

Sean B:

Who is doing it? How large are your companies? When in your production
cycle does it occur and how long does it take? What gets tested? Etc.?


> The first company was a large aerospace firm in the mid 1980s. Our
> specific plant had as many as 20,000 employees, as few as 8,000 (and
> managed to hit both the high and low in one 12-month period.) Our product
> was very large aircraft. There were about 60 tech writers on staff, and
> the tech pubs QA department had six full-time document testers. (I later
> found that under ideal conditions, that ratio of one tester to ten writers
> was just about right.)
> 
Where in the production cycle? Fairly early on in the doc cycle, in fact
before the editors would do their review. (One of the editor's job was to
double-check for correct incorporation of the validator's comments.) Keep in
mind that this being an airframe factory, we had a very long lead time
between when an engineering change would take place and when the hardware
would be delivered to the customer. Last-minute changes simply didn't
happen. When a completed airplane hit the ramp, there was still a month of
flight test before it would be delivered to the customer. Plenty of time to
get the changes in. 

The doc testers at this company were considered part of tech pubs for about
half the time I was there. Later, due to customer request (to avoid the
appearance of conflict of interest) the pubs QA group was moved into a
separate, non-pubs QA organization.

> The most recent company (the telecom) had about 900 employees, of which
> about 25 were tech writers. I submitted the idea for creating the doc
> testing position during the ISO 9000 certification process. The idea was
> accepted, and I was moved into the newly created position in the QA
> department. Doc testing took place very late in the release cycle, I was
> doing the doc testing during the software QA phase. (Well, when else can
> you do it?)
> 
What got tested? In both cases...-everything-. Well, everything that was
either new or changed for the upcoming deadline. In the case of the telecom,
that included:

* software installation procedures
* new system configuration procedures
* new screen shots (compared the doc page to system output and to
engineering spec)
* new fault/diagnostic messages 
* new views of hardware/boards
* new hardware installation

...and anything else that just seemed appropriate to test. 

Really, anything that the writers had produced. If it was a procedure with
steps, I'd do 'em on a test system. If it was a screen shot, I'd check it.
If it was a new component going into the rack, I'd either install it or
arrange to be present while others installed it (and ensure that they
followed the draft procedures for an installation). New hardware
installation, BTW, is probably the most tricky: in one memorable case the
writer had gotten bad info from the SME, and we burned out some critical
components on two test systems before we were able to resolve the problem. 

I was testing something on the order of four or five hundred pages per year.
It kept me busy. 

> --Rick Lippincott
  Saugus, MA




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out RoboDemo for tutorials! It makes creating full-motion software
demonstrations and other onscreen support materials easy and intuitive.
Need RoboHelp? Save $100 on RoboHelp Office in May with our mail-in rebate.
Go to http://www.ehelp.com/techwr-l

Free copy of ARTS PDF Tools when you register for the PDF
Conference by May 15. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com

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