Devs are challenged to solve bugs all the time. Approaches vary wildly, there’s no debugging skills academy, no testing rules, no QA canon. So even when there are a lot of methodologies, we thought about making your life a little easier with this attempt to a champion debugging guide.
Following a debugging guide can help you spot bugs in advance, prevent crashes, and, hopefully, optimize your software performance. No matter if it’s about an issue reported by users, a failing to compile, or a complete crash, here’s our bet.
The golden QA process for squashing bugs
1. Clarify your problem. The more context you have, the more chances to solve it. If you want to fix it, you have to first know what it is.
2. Do some research. Once you have spotted the problem, explore to see if someone else has encountered the same situation. Most of the issues are not new and have been already solved by someone.
3. Experiment. Once you have found the possible solution, try it out for your specific product and context.
4. Work by iterations. If your experiment didn’t work out, go back to the first step.
Specific strategies for debugging
1. Bugs are not always in the most obvious place. If you have been searching for a while and you have a good logging system, you can always try a panoramic search there, to narrow down options.
2. Previous versions are a safe place when you can’t fix something. If you have been working on a new code:
a. You might have a theory. First, try every hypothesis on what could have been wrong.
b. If none of your hypothesis worked out, go back to the latest version and re-add new code by segments, until it stops working. In this way, you can spot the segment that’s causing trouble.
3. Use different resources.
a. “Wolf-trap code”: writing a failing test will reproduce the problematic code but in a constrained way, allowing you to identify it and isolate it.
b. Work backward: set breakpoints and explore what happened preceding the bug.
4. If you’re overwhelmed, do something different. As every time you need to solve a problem and you find yourself stuck, usually, the best thing to do is to stop trying and let it flow for a while. Take a break, walk around, rest a beat. Another great idea to unblock your brain is to get off the computer. For instance, you can print your code and read it from paper. You can also use post-its to visualize your hypotheses in another kind of display like a chalkboard, rather than a screen.
5. Do pair programming, four eyes see better than two, always. Once you already are facing the bug, sharing with someone else is most of the time helpful. Explain the problem in a kind of rubber duck debugging mode. Exposing issues to different perspectives and experiences will help you squash bugs.
6. Be willing to destroy everything and restart. Sometimes you’ll have to throw away your code. Don’t worry, go step by step. At first, it might only be necessary to delete or comment on just a couple of sections of the codebase.
7. Adopt new strategies. Work in advance with automated testing. Write tests with anticipation so you can get ahead of bugs and prevent them.
Forget about debugging headaches
Stop rewriting from scratch. The task of spotting and removing bugs doesn’t have to turn into a headache. Breath and go over our debugging guide anytime you need it.