home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / sys / mac / oop / macapp3 / 334 < prev    next >
Encoding:
Internet Message Format  |  1993-01-04  |  2.1 KB
  1. Path: sparky!uunet!spool.mu.edu!olivea!apple!applelink.apple.com
  2. From: PHILMONT@AppleLink.Apple.COM (Philmont SW Mill, Jesse Feiler,PAS)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re: Takeover - QA
  5. Message-ID: <726156743.3640369@AppleLink.Apple.COM>
  6. Date: 4 Jan 93 14:05:00 GMT
  7. Sender: daemon@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 37
  10.  
  11. Dave,
  12.  
  13. I beg to differ with your approach to QA. Bernadette is right in that a full
  14. set of QA is needed for every bug fix (or set thereof).
  15.  
  16. You discuss a bug-fix and use phrases like "guaranteed" and "cannot possibly
  17. cause..." Don't tempt fate.
  18.  
  19. Without discussing this particular bug, I can easily conjure up a number of
  20. scenarios where this type of bug fix could cause problems. E.g., pushing the
  21. size of a code segment up by a few bytes - just enough to cause overflows in an
  22. application that links user code into that segment.
  23.  
  24. I participated in a "harmless bug fix" that inserted an extra blank in a title
  25. string in order to correct a slight off-centering. Because the gods of software
  26. were playful that day, this insertion of ONE BLANK (" ") in the format string
  27. led directly to the total collapse of the major financial data entry system at
  28. a very sensitive institution. Data entry workers who should have started keying
  29. at 8 AM started at 2:30 PM.
  30.  
  31. I periodicially look at the official bug list, and -- as most people do -- I
  32. file away MacApp.Tech$ links that look as if they may touch on bugs/solutions
  33. that we may need in the future. We apply bug fixes if we need them (and we
  34. usually can do them in subclasses of our own) and rely on MacApp which has been
  35. thoroughly QA'd to remain imperfect but stable.
  36.  
  37. Finally, you write, "[why do all of these discussions insist that all bug work
  38. and QA needs to be done in a vacuum???]". The answer is because the greater the
  39. degree of separation between the coder and the tester, the more likely the
  40. testing is to be thorough. I know of one case in which the testing staff isn't
  41. even told what specific bug fixes are to be tested: they are to insure the
  42. complete integrity of the new code; on a second pass, they test the specific
  43. fixes.
  44.  
  45. Jesse
  46.  
  47.  
  48.