BUG
• A software bug is an error, flaw, failure, or
fault in a computer program or system that
causes it to produce an incorrect or
unexpected result, or to behave in unintended
ways.
DEBUG
• Debugging is a methodical process of finding
and reducing the number of bugs, or defects,
in a computer program or a piece of electronic
hardware, thus making it behave as expected.
• Debugging is a necessary process in almost
any new software or hardware development
process, whether a commercial product or an
enterprise or personal application program.
DEBUGGING PHILOSOPHY
Guiding Steps:
1) Think about why you
believe the program should
produce the output you
expected.
2) Make assertions until
you understand how your
view differs from the
computer’s.
Coder: code
will produce
output X …
Computer:
code will
produce Z….
WHY DEBUGGING IS HARD
• There may be no obvious relationship between the external
manifestation of an error and its internal cause.
• Symptom and cause may be in remote parts of the program.
• Changes (new features, bug fixes) in program may mask (or modify)
bugs.
• Symptom may be due to human mistake or misunderstanding that
is difficult to trace.
• Bug may be triggered by rare or difficult to reproduce input
sequence, program timing (threads) or other external causes.
• Bug may depend on other software/system state, things others did
to you systems weeks/months ago.
TYPES OF BUGS
 Compile time: syntax, spelling, static type mismatch.
 Usually caught with compiler
 Design: flawed algorithm.
 Incorrect outputs
 Program logic (if/else, loop termination, select case, etc).
 Incorrect outputs
 Memory nonsense: null pointers, array bounds, bad types, leaks.
 Runtime exceptions
 Interface errors between modules, threads, programs (in particular, with
shared resources: sockets, files, memory, etc).
 Runtime Exceptions
 Off-nominal conditions: failure of some part of software of underlying
machinery (network, etc).
 Incomplete functionality
 Deadlocks: multiple processes fighting for a resource.
 Freeze ups, never ending processes
WHY DEBUGGING IS IMPORTANT?
Debugging is the group of activities that software developers
perform to fix a bug, so being a good debugger is a very important
part of being a good developer.
3 reasons to consider debugging one of your main skills:
We spend a lot of time debugging. By improving your debugging
skills you are likely to change this balance so that you can spend more
time coding new features.
There are always errors in your code and you will have to debug
them without introducing new errors. There are two famous quotes
that illustrate this.
Debugging is sometimes the only way to check that some code is
working fine.
3 CONSEQUENCES OF BEING A BAD DEBUGGER
• Low productivity. Debugging is one of the main activities when
developing software, bad debuggers will have to spend more time
debugging and that will affect their productivity.
• Identifying error is very difficult task, errors are like icebergs: their
visible part is just 10% of the problem, which is the only part that
bad debuggers are going to look into, leaving the other 90% alone
ready to cause some titanic catastrophe.
• Collateral damage. Modifying code to fix an error has the risk of
generating a completely new one, bad debuggers are likely to forget
about this and will create some collateral damage every time they
try to fix a bug.
7 STEPS TO FIX A BUG
Step 1. Identify the error.
 This is an obvious step but a tricky one, sometimes a bad
identification of an error can cause lots of wasted developing time,
is usual that production errors reported by users are hard to be
interpreted and sometimes the information we are getting from
them is misleading.
TIPS TO IDENTIFY ERROS
 See the error. This is easy if you spot the error, but not if it comes
from a user, in that case see if you can get the user to send you a
few screen captures or even use remote connection to see the error
by yourself.
 Reproduce the error. You never should say that an error has been
fixed if you were not able to reproduce it.
 Understand what the expected behavior should be. In complex
applications could be hard to tell what should be the expected
behavior of an error, but that knowledge is basic to be able to fix
the problem, so we will have to talk with the product owner, check
documentation… to find this information
 Validate the identification. Confirm with the responsible of the
application that the error is actually an error and that the expected
behavior is correct. The validation can also lead to situations where
is not necessary or not worth it to fix the error.
STEP 2. FIND THE ERROR
 Once we have an error correctly identified, is time to go through
the code to find the exact spot where the error is located, at this
stage we are not interested in understanding the big picture for the
error, we are just focused on finding it
Step 3. Analyze the error.
 This is a critical step, use a bottom-up approach from the
place the error was found and analyze the code so you can
see the big picture of the error, analyzing a bug has two main
goals: to check that around that error there aren’t any other
errors to be found, and to make sure what are the risks of
entering any collateral damage in the fix.
Step 4. Prove your analysis
 This is a straight forward step, after analyzing the original bug
you may have come with a few more errors that may appear
on the application, this step it’s all about writing automated
tests for these areas .
Step 5. Cover lateral damage.
 At this stage you are almost ready to start coding the fix, but you
have to cover your ass before you change the code, so you create or
gather all the unit tests for the code which is around where you will
do the changes so that you will be sure after completing the
modification that you won’t have break anything else. If you run
this unit tests, they all should pass.
Step 6. Fix the error.
 That’s it, finally we can fix the error!
Step 7. Validate the solution.
 Run all the test scripts and check that they all pass.