Troubleshooting technical problems
Throughout my career, I have dealt with all sorts of technical issues. I have troubleshot the following: dead computers, lagging network connections, e-mail accounts, computer-monitor issues, server accounts, application crashes…and a whole lot more. At each turn, I have tried to use my ingenuity to overcome certain challenges that have come my way. Of course, I tend to follow the CompTIA model of solving problems.
CompTIA (Computing Technology Industry Association) is a trade organization that promotes standard knowledge for information technology professionals. One of their most useful knowledge base is their methodology on solving problems, which is broken down as: identifying the problem, developing a theory, testing the theory, creating a plan of action, implementing the solution, verifying system functionality, and documenting the issue
Identifying the Problem
Before tackling any technical problem, you must identify what it is that you will be working on. You should gather as much detail as possible, including testimony from users who reported the problem. Get pertinent information, such as what is the reported problem, where is the location of the issue, when did it start manifesting, and who was the person who witnessed the problem. Also, verify the type of physical machine that you will be working on, the operating-system version, and the applications that might have been running on the system.
Developing a Theory
After gathering and processing all the information in order to identify the problem, you should develop a theory on probable cause. As “Occam’s razor” would profess, the simplest explanation should be the right one. Of course, you should create a short list of solutions, just in case the first one does not work.
Testing the Theory
You have gathered all the necessary information in order to analyze the problem. You had the opportunity to formulate multiple solutions to the task as hand. Now, you must test whether any of your ideas actually work. Try them out, one at a time, and see if any of them work.
Creating a Plan of Action
If, after testing any of your theories, you manage to narrow the cause of the problem(s), you will have to decide on what your next course of action will be. For example, you may have to decide on whether it is best to repair a component, or just replace it with a working unit.
Implementing the Solution
After formulating the plan, and obtaining a solution, you must implement it. For example, you may have to physically install a working component in order to make the system work.
Verifying System Functionality
This is the part where you have to make sure that the issue has been solved. You should test as many features as possible, and observe any unusual behavior. You should verify that your solution is not affecting any other system functionality.
Documenting the Issue
For the benefit of future reference, you should document every step of the problem. In your information sheet, you should have relevant data, such as who made the initial report or complaint, what and when was the problem reported, your theories, plans of action, and solutions. In essence, describe the methodology that was used.
Troubleshooting Flowchart
I used the following flowchart symbols in order to make a basic troubleshooting flowchart:
Conclusion
In all kinds of technical fields, you are bound to encounter issues that will hamper system performance. However, by following a simple troubleshooting methodology, you are bound to have more success in narrowing the cause of the problems, and be able to find viable solutions.
Disclosure: Comptektronics LLC earns from qualifying purchases.