Debugging

MEETING 12
DEBUGGING
SOFTWARE TESTING
By : Ajeng Savitri Puspaningrum, M.Kom

OBJECTIVE
• Learning Debugging
Definition
• Learning Debugging Process

4
HOW TO MAKE YOUR PROGRAM WORK?
• Getting your program to work is a process with three parts, the order
of which is the subject of some debate :
• Debugging is the process of finding the root cause of an error and fixing it.
• Reviewing (or inspecting) is the process of reading the code as it sits on the
page and looking for errors.
• Testing is the process of finding errors in the code, as opposed to fixing them,
which is what debugging is all about.

5
HOW TO AVOID SOFTWARE FAILURE?
• Whenever a software fails, we would like to
understand the reason(s) for such a failure.
• After knowing the reason(s), we may
attempt to find the solution and may make
necessary changes in the source code
accordingly.
• These changes will hopefully remove the
reason(s) for that software failure.
• The process of identifying and correcting a
software error is known as debugging.

6
WHAT IS AN ERROR, ANYWAY?
• We define three types of errors in code:
• Syntactic errors
• Semantic errors
• Logic errors

7
SYNTACTIC ERRORS
• Syntactic errors are errors you make with respect to the syntax of the
programming language you’re using.
• The easiest to find because the compiler finds nearly all of them
• Typical examples of syntactic errors:
• Spelling a keyword wrong
• Failing to declare a variable before you use it
• Forgetting to put that closing curly brace in a block
• Forgetting the return type of a function
• Forgetting that semicolon at the end of a statement

8
SEMANTIC ERRORS
• Semantic errors occur when you fail to create a proper sentence
in the programming language because of having some basic
misunderstanding about the grammar rules of the language.
• Harder to find because they’re normally syntactically correct
pieces of code, so the compiler passes the program and it
compiles correctly into an object file
• Classic examples of semantic errors:
• Not putting curly braces around a block
• Accidentally putting a semicolon after the condition in an “if” or
“while” statement in C/C++ or Java
• Forgetting to use a “break;” statement at the end of a “case” statement
inside a “switch”

9
LOGIC ERRORS
• A logic error is one that occurs because you’ve made a
mistake in translating the design into code.
• The most difficult to find and eradicate
• These errors include things like:
• Computing a result incorrectly
• Off-by-one errors in loops (which can also be a semantic error if
the error is because misunderstanding array indexing, for
example)
• Misunderstanding a network protocol
• Returning a value of the wrong type from a method, and so on.

11
WHAT IS DEBUGGING ?
• Debugging is the process of finding the root cause of an error
and fixing it [1].
• Debugging is an activity of locating and correcting errors and it is
not testing but it always occurs as a consequence of testing [2].
• Debugging means detecting and removing bugs from the
programs [5].
So, we can say that
“DEBUGGING is the process of finding, correcting and removing
any detected bugs from the programs which is different from
testing but should be done.”

12
WHEN TO DEBUGGING?
• The debugging process begins with the execution of a
test case.
• Debugging is done after we executed a successful test
case.
• A successful test case is one that shows if a program
does not do what it was designed to do.

13
HOW TO DEBUGGING?
• Debugging is a two-step process that begins when you ﬁnd an error
as a result of a successful test case.
• Step 1 is the determination of the exact nature and location of the suspected
error within the program.
• Step 2 consists of ﬁxing the error.
• It starts after receiving a failure report and completes after ensuring
that all corrections have been rightly placed and the software does
not fail with the same set of input(s).

14
GUIDELINES
WHILE PERFORMING DEBUGGING
1. Debugging is the process of solving a problem. Hence, individuals
involved in debugging should understand all of the causes of an error
before starting with debugging.
2. No experimentation should be done while performing debugging. The
experimental changes often increase the problem by adding new errors
in it.
3. When there is an error in one segment of a program, there is a high
possibility of the presence of another error in that program. So, the rest
of the program should be properly examined.
4. It is necessary to confirm that the new code added in a program to fix
errors is correct. And to ensure this, regression testing should be
performed.

15
WHAT NOT TO DO
1. Don’t guess about where the error might be!
• This implies that (1) you don’t know anything about the
program you’re trying to debug and (2) you’re not going
about the job of finding the root cause of the error
systematically. Stop, take a deep breath, and start again.
2. Don’t fix the symptom—fix the problem!
• Lots of times you can “fix” a problem by forcing the error to
go away by adding code. Study the program, figure out what
it’s doing at that spot, and fix the problem.
3. Avoid denial!
• If you just “changed one thing,” and the program breaks,
then guess who probably just injected an error into the
program and where it is?

17
AN APPROACH TO DEBUGGING[ 1 ]
1. Reproduce the problem reliably.
2. Find the source of the error.
3. Fix the error (just that one).
4. Test the fix (now you’ve got a regression test for later).
5. Look for More Errors (optionally look for other errors
in the vicinity of the one you just fixed).

18
1. REPRODUCE THE PROBLEM RELIABLY
• If your error only shows up periodically, it will be much, much harder
to find.
• Reproducing the problem—in different ways, if possible—will allow
you to see what’s happening and will give you a clear indication of
where the problem is occurring.
• You’ll know when you’ve found the simplest case because with
anything smaller the behavior of the program will change—either the
error will disappear, or you’ll get a slightly different error.

19
ERRORS ARE NOT RANDOM EVENTS
If you think the problem is random, then it’s usually one of
the following:
• Initialization problem: This can be that you’re depending on a
side-effect of the variable definition to initialize the variable, and
it’s not acting as you expect.
• Timing error: Something is happening sooner or later than you
expect.
• Dangling pointer problem: You returned a pointer from a local
variable, and the memory in which that local variable was stored
has been given back to the system.

20
ERRORS ARE NOT…(cont.)
• Buffer overflow or walking off the end of an array: You have a
loop that iterates through a collection and you’re walking off the
end and stomping on either a piece of code, or another variable,
or the system stack.
• Concurrency issue (a race condition): In a multi-threaded
application or in an application that uses shared memory, you’ve
not synchronized your code, and a variable you need to use is
getting overwritten by someone else before you can get to it.

21
2. FIND THE SOURCE OF THE ERROR
There are some techniques that can be used:
• Read the code: examine the output, make a guess where the error might be
(look at the last thing that got printed and find that print statement in the
program). Understanding what the code is trying to do in the area where the
error occurs is key to figuring out what the fix should be.
• Gather data: gather data from running the test case that can includes what
kinds of input data cause the error, what do you have to do to get it to
appear—the exact steps you need to execute, how long it takes to appear,
and what exactly happens.
• Insert print statements: start putting print statements at that point and at
other interesting points in the code. Remember that many times where an
error exhibits its behavior may be many lines of code after where the error
actually occurs.

22
TECHNIQUES THAT CAN BE USED(cont.)
• Use logging: identify which variables to log and where to log the
values. The logging routines will usually create a log file that you can
then examine when the program finishes running. If you’re doing
interactive debugging, you may be able to examine the log file as you
go.
• Look for patterns: see if there’s a pattern to the code or the error
that you’ve seen before.
• Use a debugger: set breakpoints, watch variables, step into and out of
functions, single-step instructions, change code on the fly, examine
registers and other memory locations, and so on so that you can
learn as much as possible about what’s going on in your code.
• Explain the code to someone: start explaining the problem to someone
else then you’re really explaining it to yourself as well. That’s when
the inspiration can hit.

23
3. FIX THE ERROR (JUST THAT ONE)!
• Sometimes even though you can find the error, the fix isn’t obvious,
or the fix will entail rewriting a large section of code.
• Take the time necessary to understand the code and then rewrite the
code and fix the error correctly.
• The biggest problem in debugging is haste.
• When you’re fixing errors remember two things:
1. Fix the actual error, don’t fix the symptom.
2. Only fix one error at a time.

24
4. TEST THE FIX
Rerun the original test that uncovered the error—not just the minimal
test that you came up with in step 1, but the first test that caused the
error to appear.
• If that test now fails (in the sense that the error doesn’t occur any
more), that’s a good sign that you’ve at least fixed the proximate
cause of the error.
• Then run every other test in your regression suite so you can make
sure you’ve not re-broken something that was already fixed.
• Finally, integrate your code into the source code base, check out the
new version, and test the entire thing.
• If all that still works, then you’re in good shape.

25
5. LOOK FOR MORE ERRORS
• One of the truisms of programming is that 80% of the
errors occur in 20% of the code, so it’s likely there’s
another error close to where you’ve just fixed one.
• This rule is also known as the Pareto Principle.
• In the agile world, this is called refactoring. This means
rewriting the code to make it simpler so that it will make
it clearer, easier to read, and it will make finding that
next error easier.

27
OVERALL DEBUGGING LIFE CYCLE

28
SOFTWARE TESTING VS DEBUGGING
Software testing Debugging
It is the process of executing the program
with the intent of finding faults.
It is an activity of locating and correcting
errors.
It is a phase of the software
development life cycle (SDLC).
It occurs as a consequence of testing.
Once code is written, testing
commences.
The debugging process begins with the
execution of a test case.
It is further comprised of validation and
verification of software.
It attempts to match symptom with
cause, thereby leading to error
correction.
It uses unit-, integration-, and system-
level testing.
It checks the correctness and
performance of the software.

The debugging process attempts to match symptom
with cause thereby leading to error correction.
The purpose of debugging is to locate and fix
the offending code responsible for a symptom
violating a known specification.
Debugging checks the correctness
and the performance of software
to do fault detection.

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

THANK YOU
Insert the Subtitle of Your Presentation

Debugging

Recommended

More Related Content

What's hot (20)

Similar to Debugging (20)

More from Ajeng Savitri (20)

Recently uploaded (20)

Debugging