home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / security / misc / 2374 < prev    next >
Encoding:
Internet Message Format  |  1992-12-29  |  3.0 KB
  1. Xref: sparky comp.security.misc:2374 comp.org.eff.talk:8127
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!psgrain!qiclab!leonard
  3. From: leonard@qiclab.scn.rain.com (Leonard Erickson)
  4. Newsgroups: comp.security.misc,comp.org.eff.talk
  5. Subject: Re: Stupid Licenses (YUCK!)
  6. Message-ID: <1992Dec29.002107.4196@qiclab.scn.rain.com>
  7. Date: 29 Dec 92 00:21:07 GMT
  8. Article-I.D.: qiclab.1992Dec29.002107.4196
  9. References: <bhayden.724690634@teal> <1992Dec19.023609.26000@news2.cis.umn.edu> <bhayden.724865911@teal> <TDRVB3JX@cc.swarthmore.edu> <bhayden.724947398@teal>
  10. Reply-To: Leonard.Erickson@f51.n105.z1.fidonet.org
  11. Organization: SCN Research/Qic Laboratories of Tigard, Oregon.
  12. Lines: 49
  13.  
  14. bhayden@teal.csn.org (Bruce Hayden) writes:
  15.  
  16. >eoliver@ralph.cs.haverford.edu (Erik Oliver) writes:
  17.  
  18. >>Because of the variety of IBM-Compatible products out there testing for
  19. >>every configuration is unrealistic, if not impossible.  Even in the Mac
  20. >>world, there are problems that occur because of interactions between
  21. >>INITs and CDEVs with applications.  Are these bugs?
  22.  
  23. >I think that depends on how common the hardware and hardware combination
  24. >is. If the hardware is anywhere close to common, then I would contend
  25. >that it is a reasonable to test a major product on all of the common
  26. >hardware. 
  27.  
  28. The problem is that the *combinations* are unmanageable. Say the 10 most
  29. common motherboards, the 10 most common video boards, the 10 most common
  30. TSRs. Plus the 10 most common add-on devices. That gives you *ten thousand*
  31. combinations, assuming only one selection from each class. But some can
  32. exist in multiples. And you actually need to test for more than the
  33. 10 most common in some classes. 
  34.  
  35. It *isn't* practical to test even *most* interactions. All you can reasonably
  36. do is test the some "standard" configurations. (Ones that are known to 
  37. be "the standard" that everything else is supposed to work like)
  38.  
  39. >I also would contend that once you have serious problems with a specified
  40. >hardware combination (with previous releases or products) then you may
  41. >potentially have a duty to duplicate that hardware combination for future
  42. >QC testing.
  43.  
  44. Or just list that setup as one that the software *won't* work with.
  45.  
  46. >Obviously, you have a resource problem here. IBM can afford to basically
  47. >test almost anything imaginable (so why didn't OS/2 work on many non-IBM
  48. >platforms?) A small company can probably only afford to test on a limited
  49. >number of platforms and combinations.
  50.  
  51. >I disagree. We have the capability today to set an acceptable bug level
  52. >before the release, then not release until we have reached that level.
  53. >That isn't happening in many cases. Either we aren't setting the level,
  54. >or if we are, we are shipping before we get to that point.
  55.  
  56. I know of one company that is trying to do this, and you should hear
  57. the users scream about the fact that the new version isn't ready. 
  58. -- 
  59. Leonard Erickson              leonard@qiclab.scn.rain.com
  60. CIS: [70465,203]             70465.203@compuserve.com
  61. FIDO:   1:105/51     Leonard.Erickson@f51.n105.z1.fidonet.org
  62. (The CIS & Fido addresses are preferred)
  63.