Essentials of Debugging
Debugging is an essential part of software development. No matter how great of a developer, or how meticulous you code, you will run into time where your code doesn’t do what it is expected to do. Sometimes this is an error in the actual code, other times it may be an unexpected interaction that your code has with the rest of the system When this happens you have a bug. Wikipedia defines a software bug as an error in the design or implementation (coding) of a program or application. Debugging is the the process of locating the source of the bug and then fixing the underlying problem causing the bug. While it seems straight forward, bugs can be tricky as they may not present themselves in the area of code where the problem actually exists. Many times you will notice a problem in one area of the application but the actual code causing the problem is in a totally different area or even layer of the application. While it is important to understand what a bug is, it is just as important to understand what a bug is not. Network errors, server outages, and slow connection are not software bugs. You may want to update your code to better handle these situation, but they do not constitute bugs. It is important to know what is a bug so that you are not wasting your time trying to fix something that is not in your control. The process for tracking a bug is broken down here, though for most people once they’ve done it a few times it starts to become automatic. You will begin to notice patterns in the bugs you fix so that you can just know that it is in a certain place in the code and that is where you look first. These patterns aren’t perfect but they often provide a starting point. Use the information here to develop that sense of where you need to look, but remember that patterns aren’t perfect and you may have to go back and follow the bug from broad to narrow to determine what part of the code is causing the problem. Episode Breakdown Before you begin, you must be able to replicate the bug consistently. It’s not possible to fix a bug that you can’t replicate. You’ll never know if you’ve actually fixed it or if it was even are real problem to begin with. In order to be able to track and understand what is causing an issue that issue needs to happen on a consistent basis. Inputting the same values must create the same results, even if they are wrong for it to be a consistently replicable bug. The term consistently inconsistent refers to something that happens with enough regularity to be noticed but does not happen every time. Typically when you see something is consistently inconsistent it will be related to a race condition. Many times users, and even some less experienced QA, will blame the app or your code for issues with their own machine or connection. This typically stems from a lack of understanding how computers function. Slow internet connection isn’t a bug unless you are Ops. With these cases patience goes a long way in explaining to users. Check the documentation to make sure this is an actual bug and not an unexpected feature. If you are using an outside service or you didn’t write the code yourself check the documentation to make sure that you haven’t found a feature that the user didn’t know about. When you are the one building the application and QA throws something back to you check the Acceptance Criteria, if you have them, to make sure it is doing what it is supposed to be doing. The idea is to understand what a bug is and what a bug is not. A bug occurs when the application is not functioning as it is supposed to function, that doesn’t mean how a particular user expects it to function…unless that user is the product owner. Sometimes bugs aren’t actual problems with the application or the code,