Summary of Previous Lecture

⚫ Debugging
⚫ The Debugging Process
⚫ Difference between Testing &
Debugging
⚫ Bug Life Cycle
⚫ Bug Management
⚫ Reporting

1 1/5/2026
 Today’s Lecture
⚫ Bug/Defect Types
⚫ Defect Report
⚫ Methods of Debugging
Debugging by Brute Force Attack
Debugging by Induction
Debugging by Deduction
Debugging by Backtracking
Debugging by Testing

2 1/5/2026
 Bug/Defect Types
⚫ Defects that are detected by the tester are classified into
categories by the nature of the defect. The following are
the classification :

1. Showstopper (X): The impact of the defect is severe, and

the system cannot go into the production environment
without resolving the defect since an interim solution may
not be available.
2. Critical (C): The impact of the defect is severe; however, an
interim solution is available.
3. Noncritical (N): These are also the defects that could
potentially be resolved via documentation and user
training. These can be GUI defects.

3 1/5/2026
 Defect Report
Particulars that have to be filled by a tester are:

⚫ Defect Id: Number associated with a particular defect, and henceforth

referred by its ID.
⚫ Date of execution: The date on which the test case which resulted in a
defect was executed.
⚫ Severity: As explained, it can be Critical, Non-Critical and Showstopper
⚫ Module ID: Module in which the defect occurred
⚫ State:New,Open,Assign,Test,Verified,Deferred,Reopened,Rejected,Close
⚫ Defect description: Description as to how the defect was found, the
exact steps that should be taken to simulate the defect, other notes and
attachments if any.
⚫ Test Case Reference No: The number of the test case which resulted in
the defect

4 1/5/2026
 Defect Report
⚫ Owner: The name of the tester who executed the test case
⚫ Test case description: The instructions in the test cases for
the step in which the error occurred
⚫ Expected Result: The expected result after the execution of
the instructions in the test case descriptions
⚫ History of the defect: Normally taken care of the
automated tool used for defect tracking and reporting.
⚫ Attachments: The screen shot showing the defect should be
captured and attached
⚫ Responsibility. Identified team member of the
development team for fixing the defect.

5 1/5/2026
 Methods of Debugging
The methods of debugging are listed below:

[Link] by Brute Force Attack

[Link] by Induction
[Link] by Deduction
[Link] by Backtracking
[Link] by Testing

6 1/5/2026
 Debugging by Brute Force
⚫ The most common scheme for debugging a
program is the “brute force” method. It is
popular because it requires little thought and is
the least mentally taxing of the methods, but it is
inefficient and generally unsuccessful.
⚫ Brute force methods can be partitioned into at
least three categories:
1) Debugging with a storage dump.
2) Debugging according to the common suggestion
to “scatter print statements throughout your
program.”
3) Debugging with automated debugging tools.

7 1/5/2026
 Debugging by Brute Force
⚫ Storage dump is the display or printout of the contents of memory.
⚫ When a program abends, a memory dump can be taken in order to examine
the status of the program at the time of the crash.
⚫ The programmer looks into the buffers to see which data items were being
worked on when it failed. Counters, variables, switches and flags are also
inspected.
⚫ Brute force debugging method is applied when all else fails
⚫ It is the most inefficient of the brute force methods. Here‟s why;
❑ There’s a massive amount of data, most of which is irrelevant.
❑ A memory dump is a static picture of the program, showing the state of the
program at only one instant in time; to find errors, you have to study the
dynamics of a program (state changes over time).

8 1/5/2026
 Brute Force Method-Scattering Print Statements
⚫ Scattering statements throughout a failing program to display
variable values is better than a dump as it is not static and
shows the dynamics of a program, but this method, too, has
many shortcomings:
❑ Again, you are not thinking.
❑ It requires you to change the program; such changes can mask the error or
introduce new errors.
❑ It may work on small programs, but the cost of using it in large programs like
operating systems is quite large.

9
 Brute Force Method-Automated Debugging Tools
⚫ Automated debugging tools work similarly to inserting print statements within the
program, but rather than making changes to the program, you analyse the dynamics of
the program with the debugging features of the programming language.
⚫ A common function of debugging tools is the ability to set breakpoints that cause the
program to be suspended when a particular statement is executed or when a particular
variable is altered, and then the programmer can examine the current state of the
program.

10 1/5/2026
 Debugging by Induction
⚫ It should be obvious that careful thought will find most errors
⚫ One particular thought process is induction, where you move
from the particulars of a situation to the whole. That is, start with
the clues (the symptoms of the error, possibly the results of one
or more test cases) and look for relationships among the clues.
The induction process is illustrated in Figure given below:

11 1/5/2026
 Debugging by Induction
The steps are as follows:
1) Locate the pertinent data. A major mistake debuggers make is failing to take account of
all available data or symptoms about the problem. The first step is the enumeration of
all you know about what the program did correctly and what it did incorrectly
2) Organize the data. Remember that induction implies that you‟re processing from the
particulars to the general, so the second step is to structure the pertinent data to let you
observe the patterns.
3) Devise a hypothesis. Next, study the relationships among the clues and devise, using the
patterns that might be visible in the structure of the clues, one or more hypotheses about
the cause of the error.
4) Prove the hypothesis. A major mistake at this point, given the pressures under which
debugging usually is performed, is skipping this step and jumping to conclusions to fix
the problem. If you skip this step, you‟ll probably succeed in correcting only the problem
symptom, not the problem itself.
5) Fix the Error. If hypothesis is proved successfully then go on to fix the error else repeat
steps 3 and 4

12 1/5/2026
 Debugging by Deduction
⚫ The process of deduction proceeds from some general theories or premises, using the
processes of elimination and refinement, to arrive at a conclusion (the location of the
error). See the Figure

13 1/5/2026
 Debugging by Deduction
⚫ Enumerate the possible causes or hypotheses. The first step is to develop
a list of all conceivable causes of the error. They don‟t have to be
complete explanations; they are merely theories to help you structure
and analyze the available data.
⚫ Use the data to eliminate possible causes. Carefully examine all of the
data, particularly by looking for contradictions, and try to eliminate all
but one of the possible causes. If all are eliminated, you need more
data through additional test cases to devise new theories.
⚫ Refine the remaining hypothesis. The possible cause at this point might
be correct, but it is unlikely to be specific enough to pinpoint the error.
Hence, the next step is to use the available clues to refine the theory.
⚫ Prove the remaining hypothesis. This vital step is identical to step 4 in the
induction method.

14 1/5/2026
 Debugging by Backtracking
⚫ Backtracking is a fairly
common debugging approach
that can be used successfully
in small programs
⚫ Beginning at the site where a
symptom has been uncovered,
the source code is traced
backwards till the error is
found.
⚫ Unfortunately, as the no of
source lines increases, the no
of potential backward paths
may become unmanageably
large

15 1/5/2026
 Debugging by Testing
⚫ The last “thinking type” debugging method is the use of test cases.
consider two types of test cases:
⚫ Test cases for testing, where the purpose of the test cases is to expose
a previously undetected error, and
⚫ Test cases for debugging, where the purpose is to provide information
useful in locating a suspected error.
⚫ The difference between the two is that test cases for testing tend to
be “fat” because you are trying to cover many conditions in a small
number of test cases. Test cases for debugging, on the other hand,
are “slim” since you want to cover only a single condition or a few
conditions in each test case.
⚫ In other words, after a symptom of a suspected error is discovered,
you write variants of the original test case to attempt to pinpoint the
error. Actually, this method is not an entirely separate method; it
often is used in conjunction with the induction and deduction method

16 1/5/2026
 References
[1] Software Engineering by Roger Pressman
[2]
[Link]
[Link]
[3]
[Link]
[4] [Link]
[5]
[Link]
-[Link]
[6]
17 [Link]
1/5/2026