Howard Pringle <[log in to unmask]> wrote:
>I am somewhat surprised that somebody has not started a thread on
>this topic already but am I the only one to wonder just what the
>heck is happening on the quality assurance front at HP with the
>Express 3, linkedit, Powerpatch 3, Powerpatch 4 mess. Gilles
>Schipper's recent post on possibly having to backdate to 4.0 in
>certain circumstances really brought this to a head. Is this mess
>another symptom, along with problems with sales as detailed in an
>earlier thread, of some significant problems at HP?
 
<snip>
 
>
>Anyone care to reassure (or further depress) me?
>****************************************************************
>** J. Howard Pringle        **  [log in to unmask]     **
>** Library Systems Manager  **  phone: (414) 524-3688         **
>** Waukesha Public Library  **  The opinions expressed are    **
>** Waukesha, WI    53186    **  mine, Mine, ALL MINE!!(insert **
>**                          **  demented laughter here)       **
>****************************************************************
 
 
Well, I can understand your feelings, certainly on top of badly-timed
hardware problems.  With my heart in my throat, I'll offer this
response:
 
Quality Assurance is alive and well here in CSY.  We do test each
release rigorously.  In fact, the recent thread about testing HPIB
machines on the new SPU platforms leads me to think that we in CSY
do far more testing that many of our customers expect.  We still
spend more time in product & system testing than we do in product
development.
 
But consider this one particulr "patch qualification" problem.  (We
are being lazy when we call it a "linkeditor" problem, since there
really isn't anything wrong with the linkeditor).  This problem is
caused by a side-effect of how we apply patches, and a customer's
system doesn't exhibit any negative effects when patches are
initially applied.  In fact, not all patches cause this problem
in the first place.  This problem only occurs when you later try
to apply one of those problem-causing patches a second time.  While
we do have a "patch on patch" test here in the lab, the test patches
weren't the kind to cause the problem, so we never saw the problem.
So, yes, this problem did slip by us.
 
I've been in this business of preparing regular and Express releases
for customer distribution for many years -- I'm the old hand at it
here.  In the beginning, certifying releases were simple, basically
we would ship when the software passed our reliability tests.  Over
the years, we would find situations where our testing was not
adequate, and we would add more checks.  Certifying releases became
more complicated, and that old 3 page release certification checklist
grew to maybe 20 pages as we added more and more tests.  Some of the
tests were significant efforts (like our user testing program), some
were simple (like a boot of just FOS & SLT with no applications).
In general, we always allowed the addition of testing or other critera
to be easy, and we always made it difficult to waive or remove old
criteria.
 
In summary, my attitude is that I feel very bad when a problem like
this "patch qualification" problem slips through our process.  But
to be honest, we had never seen this kind of a problem before.
I'd feel worse if we didn't learn from our mistakes.  Over the years,
there were many releases that made me feel very proud, but I am more
proud of the fact that I have yet to make the same mistake twice.
 
I don't know if this assures you; I hope it does.  I'd be interested
in feedback, especially from those who have experience with the
quality of releases other than MPE/iX releases.
 
 
Jon Cohen
HP -- Commercial Systems Division