home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / software / 5188 < prev    next >
Encoding:
Text File  |  1993-01-02  |  2.9 KB  |  69 lines
  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!spool.mu.edu!wupost!cs.uiuc.edu!marick
  3. From: marick@cs.uiuc.edu (Brian Marick)
  4. Subject: Testing bug fixes - request for data
  5. Message-ID: <C099nG.BD9@cs.uiuc.edu>
  6. Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
  7. Date: Sun, 3 Jan 1993 02:02:03 GMT
  8. Lines: 59
  9.  
  10.  
  11. I'd like to start a large-scale, low-key, industry-specific research
  12. project in testing bug fixes.
  13.  
  14. I have a technique for testing subsystems (small chunks of code up to,
  15. say, 10,000 lines) which is sketchily described in parts of several
  16. papers I'll reference below and completely described in a book I'm
  17. writing.  It's mostly variations on, and additions to, standard
  18. testing techniques.  By applying the technique to real programs
  19. (especially my own), I think I've refined it to a practical balance of
  20. cost and effectiveness.
  21.  
  22. What I am shakier on is the efficient testing of bug fixes, particularly
  23. in the absence of a good regression test suite.  I'm interested in two
  24. types of testing:
  25.  
  26. - checking that a change actually fixes the bug.
  27. - checking whether the bug fix induces new bugs because of
  28.   unanticipated dependencies.
  29.  
  30. (The latter is more interesting, because harder.)
  31.  
  32. For effective testing, I could test the entire containing subsystem
  33. using the complete technique, but that's not a realistic option: too
  34. expensive.  What I need to do is specialize the technique for
  35. bugfixes, make it good at finding likely problems but not too
  36. expensive to apply to a small change.
  37.  
  38. I have approaches, but they must be tuned with real data, actual
  39. bugfixes that were incorrect or caused new bugs.  ("Tuning", of
  40. course, includes "throwing out and replacing".)  Since I work for
  41. myself, I don't have access to big bug databases.  So I thought I'd
  42. ask those who do to give me a peek into theirs.  I'll of course sign
  43. non-disclosure agreements.
  44.  
  45. You benefit by getting my advice on how that bug could have been
  46. found, by eventual publication of articles or a book that will help
  47. your testing, and by getting credit in anything I publish.  The
  48. community wisdom about testing bug fixes will grow faster, to
  49. everyone's benefit.
  50.  
  51. What do you have to do?  When you fix a bug, and that bug turns out to
  52. have been caused by a previous bug fix, you need to describe the first
  53. (bug-causing) change and what was wrong about it.  I've done this to a
  54. limited extent with one client already.  These types of bugs take time
  55. to explain (diffs often don't suffice), so you must be willing to
  56. spend up to an hour per bug (usually less).  Explaining in person can
  57. be more efficient.  I'll be in the San Jose area a lot in 1993, and I
  58. get out to Boston every once in a while.
  59.  
  60. If anyone has any helpful literature citations, I'd like those as well.
  61.  
  62. I expect to spend a few years on this.
  63.  
  64. Thanks.
  65.  
  66. Brian Marick, marick@cs.uiuc.edu, testing!marick@uunet.uu.net
  67. Testing Foundations:  Consulting, Training, Tools.
  68. Freeware test coverage tool:  see cs.uiuc.edu:pub/testing/GCT.README
  69.