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.
Alison Wyld asked about transitioning from Technical Writing to Quality
Management:
"Does anyone out there have experience moving from a technical writing role
to a Quality Management role ? I'm a TW with 20 years experience, last 10
years or so mostly doing project management. The contract I've been working
on for the last couple of years is not going to be renewed beyond the end of
the year, so I'm in tentative talks with my employer about what else I can
do for them. One identified need is for someone to formalize our quality
system. For a previous employer, I was involved in an ISO9K2K exercise, so
I figure its do-able, probably with some support/training. Anyone out there
made this move ? Any pearls of wisdom to share ?"
__________________________________
Alison:
Do you know where on the CMM Maturity Model scale your organization is? Are
they following an SDLC development program? A well-structured QA program is
a key component at the higher levels of both programs.
I went through a training program for structured product development at one
of my employers. The QA program should verify that all the product
requirements are met at all levels of testing (initial unit or component
tests as each component is completed, integration testing as components are
combined, and alpha and beta testing of the complete system) and that all
product/program options work as specified.. The QA tests and results should
specify how each test is performed, which requirement(s) is (are) verified
by each test, what condition(s) indicate(s) passing and what condition(s)
indicate(s) failure. The test records should also record the equipment
settings or software options used for each test run. Good records are
essential are especially useful for tracking down the causes of intermittent
failures or elusive software bugs.
Your technical writing skills and knowledge will transfer very well. You
will just be narrowing your focus to verification of the quality of the
product(s) you have already learned about writing documentation.
Since I can't send attachments to the list, I'll send you a sample
documentation list for a structured development program, and a sample test
plan template off list. (I can also send a copy to anyone else who requests
one off list.)
Margaret Cekis, Johns Creek GA
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Writer Tip: Create 10 different outputs with Doc-To-Help -- including Mobile and EPUB.
