Troubleshooting Methodology CompTIA’s Best Practices

The purpose of having a methodology for troubleshooting surrounding computer repair is both efficiency and documentation of the issue. To be clear, having a consistent troubleshooting procedure can be a path to success.

Section 5.1 of 220-1001 exam objectives for the CompTIA A+ exam. This page covers CompTIA’s troubleshooting methodology. The purpose of having a methodology for troubleshooting surrounding computer repair is both efficiency and documentation of the issue. To be clear, having a consistent troubleshooting procedure can be a path to success.

Computer Repair Troubleshooting Methodology Short Version:

• 1-Identify the problem

• 2-Establish a theory of probable cause

• 3-Test the theory to determine the cause

• 4-Establish a plan of action

• 5-Implement the solution

• 6-Test functionality

• 7-Document findings, actions, and outcomes

Troubleshooting Computer Repair

Computer Repair Troubleshooting Methodology

1 - Identify the problem

If you cannot state the problem in a single sentence you probably need to further isolate the issue. This is the recon stage. You need to gather information, ask the user to describe what’s happening, possibly show you the issue.

A few good questions to keep in mind: What’s happening? When did it start? Have you installed anything new? Have you changed any hardware? Look for changes surrounding the timeline to potentially identify the cause of the issue.

Where is this issue happening? The scope can help pinpoint where the issue is arising. Is it across multiple devices or isolated to a single station?

The more information you have the better you can explain what went wrong, what it is affecting, and how you may be able to correct it. question troubleshooting

2 - Establish a theory of probable cause

Once you can identify the issue, ask your self how is the system configuration causing this issue? Could the hardware be at fault? What changed to cause the issue? Can you find a better solution?

There is a balance to be struck here, remember your goal is to correct the root of the issue, but it should also be noted that in complex systems you won’t always find the root issue. Also, downtime is lost revenue, so the balancing act comes in with where to stop searching for a deeper cause and correcting the problem at hand.

For example, a client has a printer issue, they cannot print to a networked driver. You check the printer management and see that it needs the printer driver. You know that the driver should exist on the printer driver smb share and should download and install automatically. To manually download and install the driver or investigate the smb share as to why this process failed?

What I would do, I would manually install the driver and fix the problem at hand. Remember downtime is viewed negatively, begin the process looking into the root cause.

3 - Test the theory to determine the cause

Be sure to backup anything before making a change.

After that, you’ll need to come up with a good working theory or multiple theories.

Remember your goal is to correct the root of the issue, but it should also be noted that in complex systems knowing the root cause wont always allow for prevention of a failure.

To sum up, do your best to find the balance between a root cause analysis and correcting the problem at hand.

4 - Establish a plan of action

So we know what happened when it occurred, the scope of the issue, a theory on how it’s occurring, and hopefully a reason root cause to why we think it occurred.

Do we need to change the software? Did hardware get damaged because of its location or environment? A good plan lines out potential pros and cons, a fallback strategy, and a solution to prevent the issue from arising again.

For example, Karen’s computer keeps coming in because of liquid damage. She keeps it on the floor under her desk because it is noisy but intermittently spills coffee on it. Maybe you move the computer to the other side of the desk? Are the cords long enough? Maybe you put the computer on the desk? Is the fan too noisy? Does it need a quieter aftermarket fan? Maybe no coffee at the desk?

In conclusion, the key to a good plan is thoughtfulness surrounding your solution and potential pitfalls.

5 - Implement the solution

Now its time to implement that change, you may be able to do this on your own or on the other hand may need to bring in more individuals.

6 - Test functionality

First, test the functionality of the system, after that see if the problem is resolved. Secondly, look for additional issues that may have arisen.

For example, if you help someone reset an account password they may or may not know how to correct their email client on their phone. This can be a source of frustration for them later. So be the hero and solve this before it becomes another problem.

In short, learning to do some quality control on your work will help you identify the mistakes you make, reduce the frequency of those mistakes, and lead to better working experience. Finally, the key trait of someone attentive to detail is the practiced ability to evaluate their work.

7 - Document findings, actions, and outcomes

This can be critical to not duplicating work. Clear documentation on should include: What happened, when did it happen, on what did it happen, what was your solution to the problem and why did you select that solution? Bonus for how did you test the solution and what factor did you check to know that the solution was successful.

If you think of this aspect an argument you will do well with documentation. You want someone in two years to be able to read your notes, understand the problem, the scope of the problem, understand your solution and reasoning behind it and feel confident that it was corrected because of observation. This can be tricky to get right every time, often the knowledge we have about the situation becomes assumed and gets left out.

In conclusion, if you can have a coworker read it, and understand the above points without any additional information you probably on the right path.

Secondly, clear documentation also can reinforce value to the client as they attain more visibility into the IT support role. Good documentation on how you repaired their computer not only fixes the task but provides a valuable asset for the future. If the situation arises again, good documentation may reduce the meantime to repair (MTTR).