1. DEBUGGING

2. 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.

3. 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.

4. 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….

5. 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.

6. 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

7. 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.

8. 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.

9. 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.

10. 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.

11. 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

12. 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.

13. 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.

14. THANK YOU