ajeng.savitri@teknokrat.ac.id https://teknokrat.ac.id/en/

1. MEETING 13
DEBUGGING (PART 2)
SOFTWARE TESTING
By : Ajeng Savitri Puspaningrum, M.Kom

2. OBJECTIVE
• Learning Debugging
Techniques

3. Intro

4. 4
The best way to do debugging is to have a
systematic way of sneaking up on the problem
There are many popular debugging
approaches, but the success of any approach is
dependent upon the understanding of the
program

5. 5
DEBUGGING METHOD
• Of the two aspects of debugging, locating the error and correcting it,
locating the error represents perhaps 95 percent of the problem.
• So there are many techniques to do debugging, such as:
• Brute Force Method
• Cause Elimination Method
• Trial and Error Method
• Backtracking and forward tracking
• Etc.

6. Brute Force
Method

7. 7
BRUTE FORCE METHOD
• Most common and least efficient for isolating the cause of a software
error.
• We apply this method when all else fails.
• This method obtains and studies a printout of all registers and
relevant memory locations.
• All dumps should be well documented and retained for possible use
on subsequent problems.
• It requires little thought and is the least
mentally taxing of the methods.

8. 8
BRUTE FORCE METHOD (cont.)
• In this approach, memory dumps are taken, run time traces are
invoked and the program is loaded with print statements.
• When this is done, we may find a clue in the information produced
which leads to the identification of the cause of a bug.
• Memory traces are similar to memory dumps, except that the
printout contains only certain memory and register contents and
printing is conditional on some event occurring.

9. 9
BRUTE FORCE METHOD (cont.)
• Typically conditional events are entry, exit, or use of one of the
following:
• A particular subroutine, statement, or database
• Communication with I/O devices
• Value of a variable
• Timed actions (periodic or random) in a certain real-time system.
• A special problem with trace programs is that the conditions are
entered in the source code and any changes require a recompilation.
• A huge amount of data is generated, which, although may help to
identify the cause, may be difficult to manage and analyze.

10. 10
CATEGORIES OF BRUTE-FORCE
• 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.

11. 11
DEBUGGING WITH A STORAGE DUMP
• The most inefficient of the brute-force methods because :
• Difficult to establish a correspondence between memory locations and the variables
in a source program.
• With any program of reasonable complexity, such a memory dump will produce 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).
• Rarely produced at the exact point of the error, so it doesn’t show
the program’s state at the point of the error. Program actions between
the time of the dump and the time of the error can mask the clues
you need to find the error.
• Adequate methodologies don’t exist for finding errors by
analyzing a memory dump

12. 12
DEBUGGING ACCORDING TO THE
COMMON SUGGESTION
• Better than a memory dump because it shows the dynamics of a program
and lets you examine information that is easier to relate to the source
program.
• But this method has many shortcomings, such as:
• Rather than encouraging you to think about the problem, it is largely a hit-or-miss
method.
• It produces a massive amount of data to be analyzed.
• It requires you to change the program; such changes can mask the error, alter critical
timing relationships, or introduce new errors.
• It may work on small programs, but the cost of using it in large programs is
quite high. Furthermore, it often is not even feasible on certain types of
programs such as operating systems or process control programs.

13. 13
DEBUGGING WITH AUTOMATED
DEBUGGING TOOLS
• Done by analyzing the dynamics of the program with the
debugging features of the programming language or
special interactive debugging tools.
• A common capability and function of debugging tools are
to set breakpoints that cause the program to be
suspended when a particular statement is executed or
when a particular variable is altered, so it is enabling the
programmer to examine the current state of the program.

14. Cause Elimination
Method

15. 15
CAUSE ELIMINATION METHOD
• Manifested by induction or deduction and also introduces the concept of
binary partitioning.
• Data related to error occurrence are organized to isolate potential causes.
• A cause hypothesis is devised and the data are used to prove or disprove
the hypothesis
• Alternatively, a list of all possible causes is developed and
tests are conducted to eliminate each.
• Therefore, we may rule out causes one by one until a
single one remains for validation. The cause is identified,
properly fixed, and re-tested accordingly.

16. 16
DEBUGGING BY INDUCTION
• Done by a move from the particulars of a situation to
the whole
• Start with the clues (the symptoms of the error and
possibly the results of one or more test cases) and look
for relationships among the clues

17. 17
THE INDUCTIVE DEBUGGING PROCESS

18. 18
THE INDUCTIVE DEBUGGING STEPS
The steps are as follows:
1. Locate the pertinent data.
2. Organize the data.
3. Devise a hypothesis.
4. Prove the hypothesis.
5. Fix the problem.

19. 19
DEBUGGING BY 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)
• Start with a set of suspects and, by the process of
elimination and refinement, decide that the problem
must have done it.

20. 20
THE DEDUCTIVE DEBUGGING PROCESS

21. 21
THE DEDUCTIVE DEBUGGING STEPS
The steps are as follows:
1. Enumerate the possible causes or
hypotheses.
2. Use the data to eliminate possible
causes.
3. Refine the remaining hypothesis.
4. Prove the remaining hypothesis.
5. Fix the error.

22. Other
Method

23. 23
TRIAL AND ERROR METHOD
• Dependent on the ability and experience of the
debugging persons.
• Based on experience and intelligence, and also using the
‘hit and trial’ technique, the bug is located and a
solution is found.
• This is a slow approach and becomes impractical in large
programs.

24. 24
BACKTRACKING METHOD
• This can be used successfully in small programs.
• Start at the point where the program gives an incorrect
result such as an unexpected output being printed.
• After analyzing the output, we trace backward the source code
manually until the cause of the failure is found.
• The source code, from the statement where symptoms of the
failure are found, to the states where the cause of failure is
found, is analyzed properly.

25. 25
BACKTRACKING METHOD (cont.)
• Another obvious variation of backtracking is forward
tracking, where we use print statements or other means to
examine a succession of intermediate results to determine
at what point the result first became wrong.
• Backtracking and forward tracking approaches may be
useful only when the size of the program is small. As the
program size increases, it becomes difficult to manage
these approaches.

26. Debugging
Principles

27. 27
ERROR-LOCATING PRINCIPLES
• Think
• If You Reach an Impasse, Sleep on It
• If You Reach an Impasse, Describe the
Problem to Someone Else
• Use Debugging Tools Only as a Second
Resort
• Avoid Experimentation—Use It Only as a
Last Resort

28. 28
ERROR-REPAIRING PRINCIPLES
• Where There Is One Bug, There Is Likely to Be Another
• Fix the Error, Not Just a Symptom of It
• The Probability of the Fix Being Correct Is Not 100 Percent
• The Probability of the Fix Being Correct Drops as the Size of the
Program Increases
• Beware of the Possibility That an Error Correction Creates a New Error
• The Process of Error Repair Should Put You
Temporarily Back into the Design Phase
• Change the Source Code, Not the Object Code

29. 29
ERROR ANALYSIS
A careful analysis might include the
following studies:
• Where was the error made?
• Who made the error?
• What was done incorrectly?
• How could the error have been prevented?
• How could the error have been prevented?
• How could the error have been detected
earlier? Careful

30. References
Chopra, R. (2018). Software Testing: Principles and Practices.
Mercury Learning & Information.
02
Majchrzak, T. A. (2012). Improving Software Testing: Technical And
Organizational Developments. Springer Science & Business Media.
03
Myers, G. J., Sandler, C., & Badgett, T. (2012). The Art Of Software
Testing. John Wiley & Sons.
04
Dooley, J. F., & Dooley. (2017). Software Development, Design and
Coding. Apress.
01
Singh, Y. (2011). Software Testing. Cambridge University Press
05

31. THANK YOU
Insert the Subtitle of Your Presentation