Re: testing the documentation

Subject: Re: testing the documentation
From: "Mark Baker" <mbaker -at- omnimark -dot- com>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Wed, 16 Feb 2000 16:35:15 -0500

Kim Forbes

> Next Tuesday, I am going to do a documentation usability test with future
> users of the application I am documenting. Has anyone had experience with
> this sort of thing? Can anyone give me some pointers?
>
> The application is an electronic medical record, and the users are nurses
> and support staff. I was given a list of about ten things that users were
> expected to do with the application. For example:
> 1. Add a parameter
> 2. D/C a parameter
> 3. Add a medication
> 4. Change a med time/dose once a dose has been given.

It depends on the results you want.

If you want to demonstrate that your document is very usable, make sure that
the instrucutions the test users are given map exactly to the headings and
the organization of the docs. Their task becomes to find the required
procedure by matching the title and perform the procedure. Unless your
procedures are actually wrong, you will get very high ratings from this
approach.

If you actually want to know how usable the system is, you need to write the
test cases in the terms the users would natually and normally use. You are
then testing to see if they can map their understanding of the problem onto
the the model of the problem presented by the software. This is the really
useful measure of usability, but you will probably get much poorer ratings.

You could, for instance, write a test case with the instrucution:

"Dr. Smith says to tell Mrs. Jones to take two asprin and call him in the
morning."

The the test system will, of course, contain no record of a Mrs. Jones, a
Dr. Smith, or a medication called "Asprin".

This is how products should be tested but almost never are.

BTW, for what should be obvious reasons, you should not be designing or
conducting this test. Even if your motives are pure as the driven snow, both
your docs and the test case you write will reflect your own view of the
problem space, and that view is one of the most important things that should
be tested. The test should be written and conducted by someone as far
removed from you and your viewpoint as possible.





Previous by Author: Re: any cons to single sourcing?
Next by Author: Re: Converting to text
Previous by Thread: testing the documentation
Next by Thread: Re: testing the documentation


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

Sponsored Ads


Sponsored Ads