🚀 go-pugleaf

bhayden@teal.csn.org (Bruce Hayden) writes:

>eoliver@ralph.cs.haverford.edu (Erik Oliver) writes:

>>Because of the variety of IBM-Compatible products out there testing for
>>every configuration is unrealistic, if not impossible.  Even in the Mac
>>world, there are problems that occur because of interactions between
>>INITs and CDEVs with applications.  Are these bugs?

>I think that depends on how common the hardware and hardware combination
>is. If the hardware is anywhere close to common, then I would contend
>that it is a reasonable to test a major product on all of the common
>hardware. 

The problem is that the *combinations* are unmanageable. Say the 10 most
common motherboards, the 10 most common video boards, the 10 most common
TSRs. Plus the 10 most common add-on devices. That gives you *ten thousand*
combinations, assuming only one selection from each class. But some can
exist in multiples. And you actually need to test for more than the
10 most common in some classes. 

It *isn't* practical to test even *most* interactions. All you can reasonably
do is test the some "standard" configurations. (Ones that are known to 
be "the standard" that everything else is supposed to work like)

>I also would contend that once you have serious problems with a specified
>hardware combination (with previous releases or products) then you may
>potentially have a duty to duplicate that hardware combination for future
>QC testing.

Or just list that setup as one that the software *won't* work with.

>Obviously, you have a resource problem here. IBM can afford to basically
>test almost anything imaginable (so why didn't OS/2 work on many non-IBM
>platforms?) A small company can probably only afford to test on a limited
>number of platforms and combinations.

>I disagree. We have the capability today to set an acceptable bug level
>before the release, then not release until we have reached that level.
>That isn't happening in many cases. Either we aren't setting the level,
>or if we are, we are shipping before we get to that point.

I know of one company that is trying to do this, and you should hear
the users scream about the fact that the new version isn't ready. 
-- 
Leonard Erickson		      leonard@qiclab.scn.rain.com
CIS: [70465,203]			 70465.203@compuserve.com
FIDO:   1:105/51	 Leonard.Erickson@f51.n105.z1.fidonet.org
(The CIS & Fido addresses are preferred)