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:Docs not tested etc... From:Saeed Khan <saeed -at- VIZBIZ -dot- VIZBIZ -dot- COM> Date:Mon, 15 Aug 1994 11:29:04 -0400
Hello,
I have been following some of the comments on this thread (but not
all of them) and here are a few of my thoughts on what I have read.
Some of these thoughts have already been mentioned by others but
bear with me.
What I have found (in my own experience, and from others) is that
in many cases good, tested, complete etc. documentation on it's own
is not considered important. In many software product specifications,
documentation is never spec'ed out. Typically, (and I have seen it
many times) documentation is listed as a 'required' part of
the product, but what actually falls into the documentation is never
really considered until much later in the development cycle. So the
task of actually testing the documentation once it is complete is
also never put in the development cycle.
Two points come from this.
First, as more and more documentation goes online (ie. is turned into
software) the need for testing it will become more important and
more evident. Think of it this way. If an instruction is incorrect
in a manual, it is not considered a bug. If the same instruction is
incorrect in an online tutorial, or in something like a 'wizard' (a
wizard is Microsoft's term for a type of interactive help), this
would definitely be a bug, and would require testing and fixing the
way other software bugs are treated.
Secondly, in the absence of this 'online' component, what can be
done is bring other non-software aspects of a product- support and
training- into the picture. So now, documentation, training and
support form a set of inter-related components of a software product.
All of these three components must work together. The support staff must
know what is in the documentation to perform their job well. The
training staff should make their students comfortable with the
docs, and the documentation staff must do their job well, or else the
support group will be required to do extra work.
In my company, this is how things work (though the relationships are a
little more complex), and we call this function Customer Education. I
really don't want to go into a lot more detail in this message, but
I was wondering what comments the rest of you have.
