Now What? Verifying the Fix and Logging What You Learned (Part 6)
Welcome back to my CompTIA A+ 1200 series! I am doing something different and writing about my journey to studying for this new certification using the study tools available to me at my job.
These are the previous parts of this series on my website:
Preparing for CompTIA A+ 1200 series (Part 1)
I Eat Tacos Every Valentine’s Day (CompTIA troubleshooting acronym, Part 2)
Identifying the Problem (New CompTIA A+ Part 3)
Theory Crafting, Theory Testing, and Escalating (1200 CompTIA A+ Part 4)
Action Plan and Documentation (1200 CompTIA A+ Part 5)
So in this part we’re discussing what happens after you think you’ve solved a tech issue. It’s tempting to move on the second things seem to work — but don’t skip this step.
Verify the fix.
Checking for side effects.
Write clear documentation.
These are the steps that separate a quick fix from a real solution. Plus, your future self (and your coworkers) will thank you.
When you apply a solution, ask three questions.
Did our solution fix the reported problem with the machine?
Can work still be done or is our troubleshooting now a big bottleneck?
Is there anything else we can test to see if it works normally? Tests could involve any of the following:
Trying to use a machine or miming the act that broke everything
Inspecting a component to see whether it is properly connected or damaged
Checking for status or lights or smoke that indicates a problem
Consulting logs and software tools to confirm proper configuration
Installing software updates
Before you call it quits, you should satisfy your own mind and the customer that you did everything you possibly could as a technician.
Maybe it is fixed, maybe it is not fixed, but no matter what, write down and restate what the problem was, how you as a technician responded to resolve the problem, and then confirm with the customer that the incident log can be closed or if it needs to be revisited by you or another technician.
How It Might Look IRL (In Real Life):
IT troubleshooting usually starts with a user requesting help. It could be an email, Slack message, text message, and so on, but it also could be a ticketing system
Here’s what you learn:
Who has what problem and what its status is.
A description of the problem with text, screenshots, maybe even a screen recording
Your job as a technician is to note the parts of the scenario useful for your troubleshooting investigation, and then consult the troubleshooting "Knowledge Base" or Frequently Asked Questions (FAQs) to see if anything relates to your issue.
Study these FAQs! FAQs can help you analyze IT infrastructure, gather statistics on what types of problems occur, and how frequently.
This helps at the individual level, at the company level internally, and with third-party support companies, who often ask similar questions to provide the value they must achieve in service contracts with you and your company.
You just completed a problem, hooray! Did someone else already do it and write about it? What did you write about it?
When you complete a problem and don’t write about it, you did yourself a disservice. People other than you may come to rely on your writing to solve problems in their lives.
Also, these writings may be edited for presentation to customers as proof of troubleshooting activity.
