Don't Panic
Be it at your desk or at a quality analyst's cabin or even when reading the mail of the bug raised, key idea is not to panic. There will be moments of critical issues being reported in a difficult time of a milestone. One should overcome the mental fights and focus on what the issue is.
Give importance to key details
Now you are in the place of a crime scene. You are investigating the crime scene. So take note of every available details in the console, the behavior, debug logs if any, etc. Get back to your desk and analyze the data you collected. You might have some thoughts right away if you are lucky.
Don't believe the bug in first place
Once the issue is raised, a confident developer will first doubt the tests as to why the bug would occur. So get in touch with the tester directly and squeeze him for details until you are convinced. Ask him to reproduce, test in different configurations/environments, etc. I'm sure a good tester would be free to respond to your queries.
"It is not a bug"
Sometimes, you may have faced issues where the cannot be accepted as a bug. As a developer who knows the in and out of the product can call it an invalid bug right away. In other cases, devs can discuss with their peers on the validity of the bug.
Diff of your code
Even after all the above steps, if you agree on the bug, first thing you would want to do is check the diff of the code in which the bug occurred and the last commit. This really helps anyone on the first level.
Debuggers
I'm a huge fan of debuggers. Debuggers like gdb are really useful if you know how to use them. All the IDEs these days also have an inbuilt debugger. Code editors like Atom, VS code have plugins for debugging. Keep breakpoints and identify where it occurs. They work like a charm!
Don't be this guy. ROFL. |
Debug logs matter
Religiously go through the debug log line to line and try to locate everything in your code. Sometimes the exception/crash may have occurred in a third party module also. So it is vital that everything is logged with right levels.
Take breaks
Mostly you would like to go with the flow and debug the issue. But sometimes it may prolong and you surely have to take a break and come back to resume the process freshly. I'm sure you will have new thoughts when you do.
Talk with peers
In case of the debugging process is turning out too long and eating up a significant amount of time in your JIRA, don't hesitate to have a word with your peer about what has been going on. Make him understand the situation, he may suggest you some ideas that may really work. Or he may even take different calls according to the situation.
Suggested read : Highly useful SDK development tips.
Comments
Post a Comment