The Art of Software Testing by Glenford Myers : Chapter 7

Debugging is defined as determining the exact nature and location of the suspected error within the program and fixing or repairing the error.

The author then discusses debugging methods:

1. Brute-force debugging: It is the most inefficient and unsuccessful method and advises to use this only when all other method fails. The author discusses three methods of brute-force debugging.
• Debugging with a storage dump: This is the most efficient method and the author provides a list of problems associated with this method including static nature of the dump, massive amounts of irrelevant data, etc...
  
• Debugging with scattered print statements: The author also enlists the shortcomings of this technique such as massive amount of data, require to change program, etc...
• Debugging with automated debugging tools: The author compares debugging with solving a homicide and emphasizes the use of brain over a set of aids.
  
2. Debugging by Induction: The author provides steps in the induction process as follows:
• Locate the pertinent data
• Organize the data
• Find relationship among data
• Devise a hypothesis
• Prove the hypothesis
3. Debugging by Deduction: The author provides steps in the deduction process as follows:
• Enumerate the possible causes
• Use the data to eliminate the possible causes
• Refine the remaining hypothesis
• Prove the remaining hypothesis
4. Debugging by Backtracking: In this method, mental reverse execution of the program is performed in which values of variables and state of the program is deduced by looking at the wrong output and the process is continued till the origin of the first unexpected state.
   
5. Debugging by Testing: Separate set of "slim" test cases are developed to provide information useful in locating a suspected error.

The author then provides two set of principles:

1. Error locating principles
2. Error repairing principles
• When there is one bug, there is likely to be another.
• Fix the error, not just the symptom of it.
• The probability of fix being correct is not 100%.
• The probability of the fix being correct drops as the size of the program grows.
• Beware of the possibility that an error correction creates a new error.
• The process of error repair should put one back temporarily in design phase.
• Change the source code, not the object code.

The author then discusses about improvement that can be achieved by careful analysis of software errors:

1. When was the error made?
2. Who made the error?
3. What was done incorrectly?
4. How could the error have be prevented?
5. Why wasn't the error detected earlier?
6. How could the error have been detected earlier?
7. How was the error found?