home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / software / 4272 < prev    next >
Encoding:
Internet Message Format  |  1992-11-14  |  3.2 KB
  1. Path: sparky!uunet!ogicse!uwm.edu!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!duitz
  2. From: duitz@mksol.dseg.ti.com (mitchel n duitz)
  3. Newsgroups: comp.software-eng
  4. Subject: Re: Who tests?
  5. Message-ID: <1992Nov13.153637.8643@mksol.dseg.ti.com>
  6. Date: 13 Nov 92 15:36:37 GMT
  7. Article-I.D.: mksol.1992Nov13.153637.8643
  8. References: <1992Nov4.132732.27072@sei.cmu.edu> <1992Nov12.192215.18133@iqsc.COM> <kcampb.721639735@edson>
  9. Organization: Texas Instruments, Inc
  10. Lines: 54
  11.  
  12. In article <kcampb.721639735@edson> kcampb@ee.ualberta.ca (Kevin Campbell) writes:
  13. >rex@iqsc.COM (Rex Black) writes:
  14. >
  15. >>Robert Firth writes:
  16. >>>So, in conclusion, I don't think more testing, by whomever, is the answer.
  17. >>>The answer must be to work smarter, not harder; and it's pretty clear
  18. >>>for the work of Boehm, Mills and others that it is far, far better not
  19. >>>to put defects into the product in the early days than to make heroic
  20. >>>efforts to weed them out in the final days.
  21. >
  22. >>Here be dragons.  I think we need to distinguish between TQM, which is a 
  23. >>methodology for improving processes, and testing, which is a methodology 
  24. >>for finding defects.  TQM is about improving a process so that it runs 
  25. >>more efficiently and produces fewer defects.  Testing is about finding 
  26. >>defects before the customer does.  Robert, if your point is that once
  27. >>one has a _mature_ TQM program in place throughout the organization one 
  28. >>will expend fewer resources on testing and testing-related coding, then
  29. >>I'll buy that.  However, I believe it would be very foolish for any 
  30. >>company to scrap its testing efforts entirely immediately upon starting
  31. >>at TQM program.  TQM is a long term investment, while testing is a risk-
  32. >>reduction effort.
  33. >
  34. >I like the way Bersoff (et al.) handles this in the book Software
  35. >Configuration Management An Investment in Product Integrity.  In this 
  36. >book he discusses SCM as one of a combination of methods for attaining 
  37. >and maintaining product integity.  
  38. >Product integrity meaning a product:
  39. >   1) Which fulfills user needs
  40. >   2) Which can be easily and completely traced through its life cycle
  41. >   3) which meets specified performance criteria
  42. >   4) whose cost expectations were met
  43. >   5) whos delivery expectations were met
  44. >
  45. >Bersoff identifies the following product assurance disciplines:
  46. >   1) Configuration Management
  47. >   2) Quality assurance
  48. >   3) Verification and validation
  49. >   4) Test and evaluation
  50. >
  51. >The major point I'd like to emphasis is, as stated by in the above 
  52. >argument, "Product integrity" can only be achieved through 
  53. >combined efforts in all areas.  A quality product can only be 
  54. >achieved by ensuring quality at every step in the process.  
  55.  
  56. One area of "Product Integrity" that is continually being ignored
  57. is reliability.  Given the 4 assurance disciplines above does not
  58. assure quality.  Depending on the method of testing it is usually 
  59. inpossible to give a measure of software reliability.  Without random
  60. test cases based upon some sort of usage model, the testing will only
  61. take care of expected or though out cases.  The 4 listed above will give
  62. some level of confidence in the software, depending upon how serious
  63. the software engineers too verification and validation.
  64. duitz@dseg.ti.com
  65. standard disclaimer - my views and not of TI's.
  66.