I consider the ability to identify bugs the most important skill a developer can have. I certainly spend more time chasing down bugs than any other activity.
1. The first step of debugging is identify your test case. Get specifics and write them down in a notepad (not a sticky note that you’ll loose!). If someone comes to you and says ‘I can’t release orders’, ask them for a specific order that they cannot release. Then, on your machine, find that order and try to release it. If you get the same error as the user, then you have your test case.
You test case needs to be repeatable and fast. If your importing a file or running a batch that takes a fair amount of time, that is not a proper test case. The proper test case would be a modified file that only contains one row, or a script that executes your batch for a single record.
2. Take some time to understand what the program is doing. Sometimes, what a user identifies as a bug is not a bug at all. Think about what the program is doing and why. If you don’t know what the program is doing, then step through the code to find out. Look at the data objects that the program is using. Get up and walk around. I can’t tell you how many bugs I’ve make breakthroughs on while going to the bathroom or pacing around the office.
This is where software language makes a huge difference. My first company out of college had a very archaic language called cache that was very difficult to read, and used primitive structures (it was not object based). While you could step through code, doing so was difficult and tedious. Finding the values of objects and variables while you were debugging was difficult. Lastly, it was nearly impossible to execute a workflow and identify which lines of code were being executed by that workflow.
My second company used a proprietary language called Gold which was very strong in this department. It was object oriented, and read much like java or C#. In the application, you could right click and bring up a menu with several options, among witch were ‘debug object’, ‘debug next ui call’ and ‘debug ui agent’. The first gave you a view of all the variables in the current object, with the ability to snake through to see any object it referenced. The second gave you the ability to determine exactly what code lay behind any button or field. Finally, ‘Debug UI Agent’ allowed me to look at the composition of the screen or display window.
My current company uses Microsoft Dynamics, which has a proprietary language called X++. It’s a weakly object oriented language, and it doesn’t have some of the abilities I enjoyed with Gold. I’m able to get along though… the code is readable and the debugging abilities are vastly superior to cache.
3. Once you truly understand what the program is doing, it’s usually easy to fix. However, usually you’ll first arrive at a position where you think you know what its doing, but you aren’t entirely sure. Then you try to change what you think is wrong and see how that affects things. If you’re wrong, you identify something else and try that. By the time you’ve fixed the bug, you generally should be able to explain exactly what went wrong. Without a proper test case (step 1), step 3 is impossible.
4. Document your fix. If necessary, cleanup your code and then retest it. Put comments in the code, writeup a code change document, and/or create a regression test for it.
5. Make sure your fix gets committed to live properly. This is where source control comes in. If the developer down the hall has fixed some other bug, and you revert his fix to insert yours, then he’s going to be mad at you! You should test that your fix still works after your code has been moved into Test or Live.
6. Clean up production data, if necessary. If your error was in production and resulted in wrong values being saved to the database, then you need to identify the bad records and a script or other process to update them. Don’t be tempted to do this step out of order – you need to first stop the bleeding before you tend to the wound.
Joseph's Code of many colors 