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 Phase From:Bev Parks <bparks -at- HUACHUCA-EMH1 -dot- ARMY -dot- MIL> Date:Sat, 4 Mar 1995 18:01:22 MST
Mike Uhl wrote--
One of the roles I played as a technical writer during the test phase of
software for which I was writing documentation was to liaise between
the testers and the programmers. The relationship between the testers and
the programmers was often strained because testers only produce negative
results. Has hard as they try to praise the good work they see, what they
actually produced in writing were problem reports. What I tried to do was
get problem information from the testers to the programmers *before* the
testers wrote them up officially. In this way, the problems never existed.
I was able to update my documentation and the programmers corrected the
code and management was never the wiser. ;-)
========
I've been away from the List for awhile, so am picking up this
thread in the middle. The "shortcuts" Mike describes are very
common, but they are also a way of skirting the system and could
cause more serious problems in the future.
Problem reports are a vital tracking mechanism. Code changes
made in the way that Mike describes (without a written record)
are very risky when the software has formally passed into the
testing phase. Code changes in one part of the code can
sometimes affect other areas, which the programmers may not
necessarily consider in the rush to fix a problem before it can
be written up.
Some testers will retest only the area that was being tested
when the problem arose. If the coding fix had adverse affects in
another area of code--an area previously tested and
passed--potential problems will go undetected. When the problem
finally erupts in the hands of the users, the source of the
problem will take much longer to detect without the traceability
mechanism provided by documented changes.
Okay, I'm stepping down from my soapbox now...
=*= Beverly Parks =*= bparks -at- huachuca-emh1 -dot- army -dot- mil =*=
=*= "These opinions are mine, not my employer's." =*=
=*= =*= =*=