As a developer, one has to spend ample amount of time debugging software code. Unfortunately, many developers, even the more experienced ones, tend not to debug thoroughly in a rush to fix issues at the surface. This is where a tester who is through in debugging and testing can collaborate with the developer to ensure a comprehensive fix. It’s one thing to know how to write good code but it’s another thing to know how to debug the bad(or dirty) code. Fortunately, debugging, like any other skill, is both a science and an art and can be worked on to proficiency over time, with due focus, mindset change and practice.
So, firstly what does Debugging mean ???
Debugging, in the context of engineering, defined simply, means to find the source of a problem in a code base, identify the possible causes, test out hypotheses until the ultimate root cause is found; This is then followed by elimination of that cause which ensures that it will never happen again and is taken care from a regression standpoint.
At face value this sounds like fixings bugs but debugging is more than just using a debugger and changing code, until it works per requirement. So what is debugging in the true sense?
Do not start debugging the code with a Debugger(tool). Though debugger is a very effective tool, there are several other things to take on first before resorting to it. Before using the debugger, simply replicate or reproduce the error to make sure that it is actually a bug – this will help you truly debug the cause. Herein there is no point debugging the code if you are not able to replicate the bug. If you are unable to do so, collaborate with the tester to identify the exact steps to reproduce. If you are still unable to reproduce, insert logging statements in your code, for what may sometimes be intermittent issues.
THINK ABOUT CAUSE!
After you reproduce the issue/bug, the very next step is one most software developers skip in their eagerness to solve the problem—but this step is crucial and truly quite just requiring the engineer to think. One has to look at the possible various causes of the bug before starting debugging, including a view into additional impacted areas.
CHECK UNIT TEST
As a next step check your unit tests with possible causes and add the test cases if any that may be missed. Every time you write a unit test and it passes, you are eliminating possibilities. In all simplicity, it is like traveling a road with check-points along the way and clearing them one by one before reaching a destination with the flexibility of going back to a certain checkpoint in case of failures.
NOW DEBUG, FIX BUT WHY
At last, when you are not able to write a unit test to test the possible cause of a bug, start the debugger but a clear goal of what you need as most often we assume code works a certain way or come in with a goal of a certain input or output value. Always check your assumptions carefully and before fixing the issue know its impacted area of functionality.
TOOLS FOR DEBUGGING
A debugging tool is a computer program which is used for testing and debugging software programs. It is often a public domain software such as gdb and dbx which offer console-based command line interfaces. Examples of automated debugging tools include code based tracers, profilers, interpreters, etc.
Some of the widely used debuggers for different programming languages are:
Radare2: It is a complete framework for the reverse-engineering and analyzing the binaries, composed of a set of small utilities which can be used together or independently from the command line. It supports a variety of executable formats for different processors and operating systems.
WinDbg: It is a multipurpose debugger for Microsoft Windows computer OS.
Valgrind: It is a programming tool for memory debugging, memory leakage detection, and profiling.
Basic Flow Chart for Debugging
Debugging is a skill that matures over time. A software engineer whether a developer or a tester, I would say even a designer, business stakeholder, all need to develop the skill of debugging. Depending on the job the depth of debugging may vary, but in all, it is inevitable for all of us to be good at debugging.