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: Writing vs. Testing From:Rebecca Merck <Rebecca -dot- Merck -at- ONESOFT -dot- COM> Date:Fri, 21 May 1999 13:26:10 -0400
Almost every time I've gotten involved in a documentation project, some
smart person has said, "Gee, Rebecca, in order to learn the product,
wouldn't it be great if you participated in testing? It's not very hard,
and we need the help." It always sounds like a great idea, until you look
at the schedules. Because the heaviest workload on documentation is
concurrent with testing -- when the software is finally, finally final, the
"post code freeze" efforts kick into high gear, both testing and
documentation. They BOTH become the critical path for product release.
I've gotten VERY comfortable, from a documentation project management
standpoint, in replying that although yes it does seem like a good learning
experience, the timelines make it logically impossible for ANYONE from
documentation to be part of the testing effort.
And let's be honest -- if I wanted to be a tester, I'd have applied for a
job in QA, right? The skill sets are different, the professional
experiences are different, and the best of tech writers without a QA
background is the lowliest of testers (as Fred experienced).
It doesn't make sense to the product timeline.
It doesn't make sense in terms of best use of skill sets.
"And you just get dirty, and the pig likes it."
