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.
Subject:Re: Test Plan as User Doc??? From:Jim Purcell <jimpur -at- MICROSOFT -dot- COM> Date:Tue, 6 May 1997 15:52:01 -0700
Misti Tucker asks:
> My client has decided that having me do three projects (a test plan, a
> user doc, and a help system) would be too expensive. Their solution?
> They've
> decided to try to combine the user guide with the test plan. on the
> left hand
> page a description of the module and what it does, on the right hand
> page a
> test plan for the screen, which the user is supposed to sort through
> for
> information about how to perform the functions on that screen.
>
<snip>
> Have any of you tacked something like this? How did it work out? Did
> you have
> any luck making the abomination usable?
>
I think I can see the origins of this client's thinking. Normally both
of these documents would have a common source: the functional
specification. Engineers in high-end technical jobs often think that
with a little formatting, the functional spec will work fine as a user's
guide, and probably as a test plan, too.
That is not to say that the client's thinking is other than--let us be
charitable--hopelessly misguided. Anybody who has been through Tech
Writing 101 can recite the "Audience, Purpose, Use" mantra and see
immediately why three separate documents are required, especially when a
graphical user interface is involved. And anybody who has been around
testers can wonder why, unless Misti is also a professional tester, the
client would ask her to define the contents of the test plan.
It's hard to see how this plan benefits anybody. Both documents still
have to be written and printed, only now the user's guide is twice as
thick, and you can't throw the test plan away after the testing is over.
Since test plans don't normally require durable binding, they can't be
saving much money by putting out only one book. And apparently the
testers are out of the loop. Why would anybody want to publish
documentation this way?
Jim Purcell
jimpur -at- microsoft -dot- com
My opinions, not Microsoft's
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
