Troubleshooting
Troubleshooting in it’s core is an art that can be used with any situation. Troubleshooting is nothing more and nothing less than being able to deduce the source of a given challenge and overcome it, in another words, you find the source of the issue and fix it.
Many times troubleshooting is considered to be unnecessary or it is simply overlooked, but fact is that having it as a skill can help in many situations.
The following steps should be used as a guide to troubleshoot any kind of issue, but keep in mind that it is a guide and not the norm.
1st - there is no issue
Before determining if there is a issue, you need to prove that there is no issue. Think of it as a negative test. If someone tells you that you given application has a bug, you must prove it that there is not.
If this test fails, which means, there is a bug on your application, then you can proceed to the next steps.
2nd - there is an issue, why?
Finding the source of the issue is important and most of the times the source of the issue is not directly related to the issue to begin with.
Take this scenario as an example: Consider that you are lost, in the woods, it is cold, it is night, there is a fog and with some little help from the light of the moon you were able to find a cabin. When you get into the cabin you see that there is a gas stove, a oil lamp and a fireplace. Which one do you light up first?
The answer for this question is not as simple as it seems and, although it has many options, the path to solve this little mystery is only one: you must light up something that generates fire such as a match or a lighter.
Neither the match or the lighter were part of the options, so how could you guess that?
When troubleshooting asking the right questions will help determine the source of the issue. The goal is to find it’s source so you can properly fix it. If you consider the above scenario, choosing the options presented wouldn’t help at all and the issue would still be to be solved.
In the case of an application bug you should be asking about what portions of the code were affected, if data was affected, what is the main symptom, the scenarios in which that given bug could have been generated, can you replicate it, etc.
3rd - Determine risks
Once you determined the issue and a possible solution you must determine what are the risks of applying that fix.
Will the fix cause another issue, will it take longer to do, will it properly solve the issue. What are the risks in applying the fix for the issue.
4th - Test the solution, auto test it, and test it again
It is important that is understood that there are more than one solution for each issue that is found. In the case of the cabin in the woods the solutions would be either a match or a lighter.
Ultimately someone will take the decision of the path to take and because of it is necessary that the decision can be validated by testing it either automatically, by the person who fixed and by someone else.
Off course, as the person that develops the fix, we will test always the best case scenario. If we use an automated solution that we also develop, then we will be testing the best case scenario, even if it confirms that what we did is working and that is why having someone else validating your logic is important.
It goes back to the start, do a negative test. Consider that your solution doesn’t work and prove it that it does.
Finally
As mentioned before this is merely but a guide. For every issue there will be several ways to troubleshoot it and on it’s core, troubleshooting is nothing more than asking the right questions to determine the origin of the issue and then asking more questions to determine the solution for the issue.
