Debugging occur as a consequence of successful testing. Debugging refers to the process of identifying the cause for defective behaviour of a system and addressing that problem. In less complex terms – fixing a bug. When a test case uncovers an error, debugging is the process that results in the removal of the error. The debugging process begins with the execution of a test case. The debugging process attempts to match symptoms with cause, thereby leading to error correction. The following are two alternative outcomes of the debugging:
- The cause will be found and necessary action such as correction or removal will be taken.
- The cause will not be found.
Characteristics of bugs
- The symptom and the cause may be geographically remote. That is, the symptom may appear in one part of a program, while the cause may actually be located at a site that is far removed. Highly coupled program structures exacerbate this situation.
- The symptom may disappear (temporarily) when another error is corrected.
- The symptom may actually be caused by non errors.
- The symptoms may be caused by human error that is not easily traced.
- The symptom may be a result of timing problems, rather than processing problems.
- It may be difficult to accurately reproduce input conditions.
- The symptom may be intermittent. This is particularly common in embedded systems that couple hardware and software inextricably.
- The symptom may be due to causes that are distributed across a number of tasks running on different processors.
Life cycle of a Debugging Task
The following are the various steps involved in debugging:
a) Defect Identification/Confirmation
– A problem is identified in a system and a defect report is created.
– Defect assigned to a software engineering.
– The engineer analyses the defect report, performing the following actions:
- What is the expected/desired behaviour of the system?
- What is the actual behaviour?
- Is this really a defect in the system?
- Can the defect be reproduce?
(b) Defect Analysis
Assuming that the software engineer concludes that the defect is genuine, the focus shifts to understanding the root cause of the problem. This is often the most challenging step in any debugging task, particularly when the software engineer is debugging complex software.
Many engineers debug by starting tool, generally a debugger and try to understand the root cause of the problem by following the execution of the program step-by-step. This approach may eventually yield success. However, in many situations, it takes too much time, and in some cases is not feasible, due to the complex nature of the program(s).
(c) Defect Resolution
Once the root cause of a problem is identified, the defect can then be resolved by making an appropriate change to the system, which fixes the root cause.
Three categories for debugging approaches are:
- Brute force
- Cause elimination
Brute force is probably the most popular despite being the least successful. We apply brute force debugging methods when all else fails. Using a “ let the computer find the error” technique, memory dumps are taken, run-time traces are invoked, and the program loaded with WRITE statements. Backtracking is a common debugging method that can be used successfully in small program. Beginning at the site where a symptom has been uncovered, the source code is traced backwards till the error is found. In Cause elimination, a list of possible causes of an error is identified and tests are conducted until each one is eliminated.