- [Instructor] The CompTIA A+ troubleshooting process
can be very helpful when it comes
to repairing computer issues.
For example, fixing an IP configuration problem
or perhaps ending a process
so that a non-responsive application will close.
The possibilities are endless.
You never know what you might have to fix
but you do know that you will be troubleshooting
on a regular basis.
To do so effectively requires the use
of a troubleshooting process.
Let's talk about troubleshooting methodologies now.
Troubleshooting processes are designed
to help you logically solve problems.
When you troubleshoot in a step by step fashion,
you're more likely to one, notice the obvious.
The obvious problem and the obvious answer.
Two, understand why more complicated problems
will occur and three, solve any type
of problem faster and more efficiently.
Remember to apply a troubleshooting process
whenever you face a problem, especially difficult ones.
You should write out the troubleshooting process,
write out what the problem is
and how you are attempting to fix it.
This helps you learn how to troubleshoot better
but also the simple act of writing this out
or talking it out can help you
to figure out the actual problem.
Now, there are many different troubleshooting
methodologies out there.
Ultimately you will need to use the one that works best
for you or for your organization,
but for many technicians the CompTIA A+
troubleshooting process works very well.
So let's discuss that now.
The CompTIA A+ troubleshooting process is defined
in the A+ objectives.
If you haven't downloaded those yet,
I highly recommend that you do so.
Download them from the compTIA website and print them out.
You'll be referring to these often.
The process is broken down into six steps.
Step one, identify the problem.
You want to question the user, identify any user changes
to the computer and perform backups before you make
any changes to the computer.
Step two, establish a theory of probable cause.
And you want to question the obvious,
start with the most likely cause.
Step three, test the theory to determine the cause.
Once the theory is confirmed, determine the next steps
to resolve the problem.
If the theory is not confirmed, then you wanna reestablish
a new theory or escalate the problem
to someone who can help you.
Step four, establish a plan of action
to resolve the problem and implement the solution.
And again, escalate it if necessary.
You know, you might have to bring in another tech.
You might have to talk to a manager,
no one technician knows everything.
Number five, step five is verify full system functionality
and if applicable, implement preventive measures.
So make sure you test the system and step six,
document findings, actions, and outcomes.
Memorize these six steps.
Before we go any further,
it's very important to always consider any corporate
or organizational policies, procedures,
and impacts before implementing any changes.
Let's go ahead and illustrate this troubleshooting process
as a flow chart now.
Okay, here, we have a basic diagram
of this six step troubleshooting process.
We'll start from the left and move to the right.
First, the problem occurs.
And the first thing you wanna do really is open a ticket.
Most companies, most organizations will have some type
of trouble ticketing software,
or some type of paperwork that you'll need to start.
And so you're gonna wanna do that.
Documentation is an ongoing process unto itself.
So this documentation will continue.
This ticket will continue
until the end of the whole process.
But step one is identifying the problem.
You're not actually doing anything yet.
You want to go to the computer, look at it, listen to it.
You want to gather information.
You want to identify symptoms.
Then you want to question the user.
You're not blaming the user.
You're just questioning the user to find out
what happened to the computer, were any changes made.
Determine if anything has changed
since the last time the computer worked,
that's all part of step one.
You're not doing anything really to the computer
but you're identifying what the problem is.
Also during step one, you want to inquire with the user
or users regarding any environmental
or infrastructure changes,
and you should also review the system and application logs
and any other logs that you can get your hands on.
It's so important to identify the problem.
If you do it properly, it'll save you a lot
of time through the rest of the troubleshooting process.
So gather information, don't just jump
in and start typing things
and messing around with the computer.
Gather information and determine what has changed
and find out as much as you can,
identify that problem first.
Step two, establish a theory.
Well, you don't know if the theory's
gonna be correct or not.
You wanna establish something.
You wanna question the obvious.
You wanna start with the most likely,
the most likely cause you know,
if the computer won't turn on,
maybe it's not plugged in.
The most likely cause.
Then step three, test that theory.
If the computer isn't plugged in,
plug it in and see if it starts.
That will decide if the theory is correct or not.
If it's incorrect, if your theory tests negative,
then you go back to step two and establish a new theory.
If the theory tests positive and it's correct
then you move on to step four.
Step four, establish a plan of action and implement it.
You know, whatever it might be.
It could be plugging in the computer or it could be changing
out the power supply or fixing the power button.
Who knows, I don't know what the answer's gonna be.
You don't know what the answer's gonna be
until you test that theory.
So once you figure that out,
you want to establish the plan of action.
Whatever that is, fix it, implement that solution.
That brings us to step five
where you verify system functionality.
This is the second most important thing
on the list here in my opinion.
You gotta test, test everything you do.
I don't care if it's an installation, a configuration,
a troubleshooting, a problem, whatever.
You gotta test it.
Otherwise you could be caught with egg on your face.
You don't want that.
So you gotta test.
But in addition to that,
you want to implement preventive measures.
Why was the computer unplugged?
Who knows?
Maybe the power cable needs to be rerouted.
Maybe the cleaning crew disconnected it
and you wanna fix the problem.
Make sure it doesn't happen again also
and then train users as necessary.
Perhaps the user needs to be trained
on how the computer works.
A little bit more information for the user can
go a long way to you not having to respond
to the same problem again.
And once you've done that step six, document.
Again, you should have been doing this
through the whole process
but at this point you wanna summarize your documentation.
You wanna make sure that you are explaining
what the problem was, maybe how you tested it,
what plan you established,
and how you fixed the problem and that it was tested
and have everybody sign off on it as necessary.
It could be you, could be the user
that was having the problem,
could be your manager, could be a combination of all those.
So document everything.
And then the problem is solved
and you can close the ticket once everybody is signed off.
So that in a nutshell is a little flow chart
of the six step troubleshooting process.
You can write it out this way
or you could just write it out on paper step by step.
However you wanna do it.
The best thing to do is to try to visualize
what you're fixing and writing it out
helps you to visualize.
It gets some of that stuff out of your head
and onto paper and clear some space for your brain
to do more of the troubleshooting instead of having
to visualize everything in addition to that.
So definitely go with the troubleshooting process,
use it to your advantage
and it'll help you fix problems faster,
more efficiently, and be a better troubleshooter in general.
Remember, memorize this six step process
and that's the end of this video.