(Excerpts from a message dated 11-10-99, Ray Hyder to Murray Lesser)

Hi Ray--

 ML> As any programmer knows, it is impossible to test complex 
 ML> software to the point that one can guarantee that it is bug 
 ML> free.  (A very old programmer's adage is that the only bug-free 
 ML> software is software that is no longer in use!)  This is 

RH>Awwww, geeze another old programmer with excuses on why software
  >can't be tested in all situations and all configurations.  Let's get
  > to a discussion on regression testing? 

    Ay, there's the rub!  If you had read the previous paragraph
carefully before you shipped it off, it should have dawned on you that
it is impossible for any software developer or tester to predict "all
situations and all configurations" under which that software will be
used, let alone to test for all of them.  Regression testing is useful,
but the best it can do is give the tester a warm feeling that the new
release can pass all the tests that all previous releases have passed.
However, there is no way that regression testing can help determine that
fixes for bugs not found during the original testing of the product were
properly designed and implemented, or that the "fix" hasn't introduced
new, thus-far undetected, bugs in the process.  Sometimes, we old
programmers know what we are talking about :-).

    If it were possible to fully test complex software, IBM would never
have needed to institute the APAR procedure, since there would be no
user problems to report!  Most bug fixes in FixPaks arise from a valid
bug report submitted by a user: bugs that previous testing have missed,
including those that were uncovered by hardware that was not available
at the time the product was released.  Any computer user who is smart
enough to run OS/2 rather than Windows should be knowledgeable enough to
realize that if it were possible to fully test software, there would be
very few FixPaks.  We most certainly would not be up to FixPak 12 for
Warp 4, this soon.

 ML> of makes) of hardware.  You might take the time some day to 
 ML> check out how many of the new files in your newest FixPak 
 ML> replace those same-named files that were updated in a previous 
 ML> FixPak. 

RH>The fixpaks are cumulative.  Therefore every file that has been
  >fixed since fixpak 1 is included in fixpak 12.  

    If you bother to read the README file that comes with each FixPak,
you will find a list of all the files contained in that FixPak, each
with the date that file was last released.  Obviously, any file dated
the same as the FixPak itself is "new" to that FixPak.  If a same-named
file was also released on an earlier FixPak (you can tell this by
checking whether any of those "new" files were listed in the README for
the previous FixPak), the new fix is a fix for a bug introduced (or not
really fixed) in a previously issued FixPak!

RH>All I know is that OS/2 release 4 at fixpak 12 is working very well
  >here with MY set of applications...  - ray  

    Congratulations.  However, your success is no indication that FixPak
12 would work "very well" with MY hardware and set of applications.

    I have no complaints about how my present system (Warp 4 FixPak 5)
operates, and there has been no indication that any of the few "new
function" additions of later FixPaks would be useful to me.  Thus, I can
see no reason to accept your unsolicited advice to subject myself to the
aggravation of installing and testing a FixPak that offers me nothing
that I want and has the potential to cause me difficulties.  Thank you
for your good intentions, but (as I said before) yours was very poor
advice.  I mean it sincerely when I say "If it ain't broke, don't FixPak
it!"

    Regards,

        --Murray

___
 * MR/2 2.25 #120 * Nothing is so uncommon as common sense

--- Maximus/2 2.02