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.
Mark Levinson told us that documents are not tested for these reasons: (1)
Software managers don't see documents as part of the product. (2) After
software is frozen, there isn't enough time left. (3) Problems caused by
untested documents are in the future.
This may be true, but do we have to sit back and accept it as inevitable?
I don't think so. My guess is that Mark doesn't think so either.
I believe that this situation is largely the result of our attitudes and
behavior. If we can overcome our tendency to relegate ourselves to a minor
role in development programs, behave as the competent professionals we
believe ourselves to be, and integrate ourselves early into the
development process, there is no reason why documentation can't be
developed in parallel with product development. If the product and its
documentation are tested throughout the development process, the
documentation can be tested and ready with the software distribution
media. This results in better products with better integral documentation.
I've seen many products developed with this process. The technical
communicators who worked on these projects are proud and confident.
