Re: Test Phase

[Robert Plamondon <robert -at- PLAMONDON -dot- COM>]

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.  ;-)

Bev Parks responds:
>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.

Well, the entire point of the exercise Mike described is to have the
software tested with the help of the testers BEFORE the official test
phase.  You test it during the development phase, so you can make
sure you're developing something that works.

This sort of under-the-table quality conspiracy has always been around,
but, since it flies in the face of corporate class strictures, crosses
department lines, and depends on the desire to produce a better product
as its sole motivating factor, it doesn't fit in with corporate
thinking very well, and is constantly being forgotten and reinvented.

My dad was an aerospace engineer.  He quickly discovered that, when he
send blueprints to the machine shop via interoffice mail, as he was
told to do, the parts he got back never worked.  But if he walked his
drawings down, and asked the machinists' opinion on how to specify the
part so it was manufacturable, everything worked like clockwork.

You see, it's typical for mechanical engineers to be more or less
ignorant of machining techniques, so they have little idea of how their
parts will actually be made.  Since in machining, like in everything
else, there are a finite number of right ways to do something, but
limitless ways of doing it wrong, things worked poorly.  It was
common to see groups of machinists poring over drawings, trying to
figure out what the engineer is trying to do -- reverse-engineering
something that has just been designed in the same building -- and
then redesigning it on the fly so that it might actually work.

Class strictures were such that engineers were discouraged from talking
to machinists, though my dad discovered that hanging out in the machine
shop was considered eccentric, but harmless.  The machinists, of
course, appreciated respectful treatment, and were also very proud of
their work -- and frustrated when bad drawings and clueless engineers
made it impossible for them to turn out a quality product.

Anyway, Dad never waited until his designs were even half-complete
before taking them down to the machine shop, because the machinists
were (not surprisingly) very skilled at making precision parts to spec,
if the spec was designed with precision machining in mind.  So there
was quite a bit of back-and-forth.

BUT -- no official mechanisms were bypassed.  Dad's drawings got all
the checking, and his parts got all the testing that anyone else's did.
It's just that, by the time he released his drawings to the checkers,
he already had a 100% perfect shop-built prototype in his desk drawer.

        -- Robert