Re: Field testing manuals

Subject: Re: Field testing manuals
From: Rick Lippincott <rjl6955 -at- gmail -dot- com>
To: "Bruce Megan (ST-CO/MKP3.2)" <Megan -dot- Bruce -at- us -dot- bosch -dot- com>
Date: Fri, 11 Sep 2015 06:11:09 -0400

If you do have an opportunity to do some field testing (or find a
customer willing to give it a go), it helps if you've got a plan and a
structure.

For example, classify tasks as to how they can be validated:

* Demonstration - someone will walk through the procedure by reading a
step, doing the step, reading the next step, doing the next
step...etc...and recording any issues.
* Simulation - used when actually performing the procedure could cause
a disruption. Same process, but it's more of a visual check of the
docs against the system.
* Desktop Comparison - bump the docs against the system by checking
the engineering data.

Which method is appropriate for a given task is a matter of
circumstances, and any given doc will likely include all three
methods.

The next thing you may want to consider is to start building a rating
system so that you can track the quality improvement. Tally the number
of errors against the number of pages. More importantly, classify the
errors according to seriousness, rate them on a scale. For example:

Defect level 5: This error could lead to death or injury, or damage to
the system.
Defect level 4: This error will cause the system to stop, and the user
will not be able to recover without assistance.
Defect level 3: This error will cause the system to stop, but the user
will probably be able to figure out a recovery method.
Defect level 2: This is an error that the user will almost certainly
be able to figure out.
Defect level 1: Typos, spelling, grammar, and other items that don't
affect meaning.
Defect level 0: It's actually correct as written, but here's a
suggestion on how to make it easier to understand.

This usually works best when someone is tasked to do a complete review
of the doc, as opposed to hoping people will remember to write down
things as they find them.

I've done this in a couple of places, and the resulting quality
improvement to the docs can be significant.

--Rick Lippincott
"I Explain Things"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Learn more about Adobe Technical Communication Suite (2015 Release) | http://bit.ly/1FR7zNW

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives


References:
Field testing manuals: From: Bruce Megan (ST-CO/MKP3.2)

Previous by Author: Re: PPT training materials, pdf output (with inter pdf/ppt project hyperlinks) --what is the best tool?
Next by Author: Re: Must documentation always follow the UI?
Previous by Thread: RE: Field testing manuals
Next by Thread: RE: Field testing manuals


What this post helpful? Share it with friends and colleagues:


Sponsored Ads