1. Bug fix analysis - taken from Rapid software testing notes by Michael Bolton
2. Problem Analysis
   1. Frequency
      1. How was the bug found?
         1. Was it found by a user?
         2. Is it a natural or contrived case?
         3. Is it a typical or pathological case?
         4. Was the bug caused by a recent fix to another bug?
      2. How often is it likely to occur?
         1. Is it intermittent or predictable?
         2. Is it a one-time problem or ongoing
      3. How soon after the bug was created did we discover it?
   2. Severity
      1. Does the bug cause any user data to be lost?
      2. Will it cause an additional load for Technical Support?
      3. How likely is the user going to notice it when it occurs?
      4. Is it the tip of an iceberg?
         1. Will it trigger other problems?
         2. Is it part of a class of bugs that should all be fixed?
         3. Does it represent a basic design deficiency?
      5. Was this bug shipped in the previous release?
         1. Did Technical Support hear anything about it?
         2. Has anything changed since the last version that would make it more or less of a problem?
      6. Is this bug less severe than others we have deferred? Is it more severe than others we have fixed?
   3. Publicity
      1. Are certain kinds of users more likely to be affected than others?
         1. How sophisticated are those users?
         2. How important are those users?
         3. How vocal are those users?
         4. Will it affect the review writers at any major magazines?
      2. Are our competitors strong or weak in the same functional areas?
      3. Is this the first release of this feature or is there an installed base?
      4. Is the problem so esoteric that no one will notice before we can update the product?
      5. Does it look like a defect to the casual observer, or like a natural limitation?
3. Solution analysis
   1. Identification
      1. Is the solution related to third-party components?
      2. What are the workarounds?
         1. Are they obvious or esoteric?
      3. Can we “document around it” instead of fixing it?
      4. Can the solution be postponed until the next release?
      5. Is a fix known?
         1. Are there several possible fixes or just one?
         2. How many lines of code are involved?
         3. Is it complex code or simple code?
         4. Is it familiar code or legacy code?
         5. Is the fix a tweak, rewrite, or substantial new code?
         6. How long will it take to implement the fix?
         7. What components are affected by the fix?
         8. Will it require rebuilds of dependent components?
         9. Does the fix impact documentation in any way? screenshots? online help?
   2. Verification
      1. What new problems could the fix cause? worst case?
      2. How effectively could we test the fix, if we authorize it?
         1. Was this bug found late in the project? Does that indicate a weakness in the test suite?
         2. Will the test automation cover this case?
      3. How hard would it be to undo the fix, if there's trouble with it?
   3. Perspective
      1. How dangerous is it to make changes in this code?
      2. Will a fix to this component be the only reason to rebuild or remaster?
      3. Who wants this fix internally? What are the politics involved?
      4. How does the overall quality compare to previous releases?
      5. If we think this bug is important, why not slip the schedule by two weeks and fix more bugs?
      6. What would be the right thing to do? the safe thing to do?
   4. Prevention
      1. Was the problem caused by a fix approved after code freeze?
      2. What was the error that caused the defect?
      3. Is there any internal error checking or unit test that should be added to catch bugs of this type?
      4. Is there any review process that could catch bugs like this before they get into the build?