0% found this document useful (0 votes)
462 views10 pages

Six-Step Computer Troubleshooting Guide

The document outlines a six step methodology for troubleshooting computer problems: 1) Identify the problem, 2) Establish a probable cause, 3) Test the theory, 4) Establish a plan of action, 5) Verify full functionality, and 6) Document findings. The steps involve gathering information, forming a hypothesis, testing solutions, implementing a plan, confirming the issue is resolved, and recording the process for future reference.

Uploaded by

Judith Nelson
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
462 views10 pages

Six-Step Computer Troubleshooting Guide

The document outlines a six step methodology for troubleshooting computer problems: 1) Identify the problem, 2) Establish a probable cause, 3) Test the theory, 4) Establish a plan of action, 5) Verify full functionality, and 6) Document findings. The steps involve gathering information, forming a hypothesis, testing solutions, implementing a plan, confirming the issue is resolved, and recording the process for future reference.

Uploaded by

Judith Nelson
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 10

H177 34 – TROUBLESHOOTING COMPUTER PROBLEMS

SIX STEP TROUBLESHOOTING METHODOLOGY


SIX STEP TROUBLESHOOTING METHODOLOGY

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 to Resolve the Problem and Implement the Solution
5. Verify full system functionality

6. Document findings, actions and outcomes


1. IDENTIFY THE PROBLEM

• In this first step you already know that there is a problem; now you have to identify exactly what it is.
This means gathering information. You do this in a few ways:

• Question the user


• Ask the person who reported the problem detailed questions about the issue
• You want to find out about symptoms, unusual behaviour, or anything that the user might have done of
late that could have inadvertently or directly caused the problem (Closed Questions)
• Of course, do this without accusing the user!
• If the user cannot properly explain a computer’s problem, ask simple questions to further identify the
issue (Open Questions)
1. IDENTIFY THE PROBLEM

• Identify any changes made to the computer


• Look at the computer. See if any new hardware has been installed or plugged in
• Look around for anything that might seem out of place
• Listen to the computer— even smell it!
• For example, a hard drive might make a peculiar noise, or a power supply might smell like
something is burning

• Define if any new software has been installed or if any system settings have been changed
• In some cases, you might need to inspect the environment around the computer. Perhaps
something has changed outside the computer that is related to the problem
1. IDENTIFY THE PROBLEM

• Review documentation
• Your company might have electronic or written documentation that logs past problems and solutions
• Perhaps the issue at hand has happened before, or other related issues can aid you in your pursuit to
find out what is wrong
• Maybe another technician listed in the documentation can be of assistance if he or she has seen the
problem before
• Keep in mind that you’re not taking any direct action at this point. Instead, you are gleaning as much
information as you can to help in your analysis.
• In this stage it is also important to back up any critical data before making any changes
2. ESTABLISH A THEORY OF PROBABLE CAUSE

• In step 2 you theorize as to what the most likely cause of the problem is
• Start with the most probable or obvious cause
• For example, if a computer won’t turn on, your theory of probable cause would be that the
computer is not plugged in!

• This step differs from other troubleshooting processes in that you are not making a list of
causes but instead are choosing one probable cause as a starting point
• In this step you also need to define whether it is a hardware or software related issue.
3. TEST THE THEORY TO DETERMINE THE
CAUSE
• In step 3 take your theory from step 2 and test it.
• Back to the example, go ahead and plug in the computer. If the computer starts, you know
that your theory has been confirmed
• At that point move on to step 4. But what if the computer is plugged in? Or what if you
plug in the computer and it still doesn’t start?
• An experienced trouble-shooter can often figure out the problem on the first theory but
not always
• If the first theory fails during testing, go back to step 2 to establish a new theory and
continue until you have a theory that tests positive
4. ESTABLISH A PLAN OF ACTION TO RESOLVE
THE PROBLEM AND IMPLEMENT THE SOLUTION
• Step 4 might at first seem a bit redundant, but delve in a little further
• When a theory has been tested and works, you can establish a plan of action
• In the previous scenario, it’s simple; plug in the computer
• However, in other situations the plan of action will be more complicated; you might need
to repair other issues that occurred due to the first issue
• In other cases, an issue might affect multiple computers, and the plan of action would
include repairing all those systems
• Whatever the plan of action, after it is established, immediately implement it
5. VERIFY FULL SYSTEM FUNCTIONALITY

• At this point verify that the computer works properly


• This might require a restart or two, opening applications, accessing the Internet, or actually using
a hardware device, thus proving it works
• Also within step 5 you want to prevent the problem from happening again if possible. Yes, of
course you plug in the computer, and in this case it works, but why was the computer unplugged?
• The computer being unplugged (or whatever the particular issue) could be the result of a bigger
problem, which you would want to prevent in the future
• Whatever your preventative measures, make sure that they won’t affect any other systems or
policies, and if they do, get permission for those measures first.
6. DOCUMENT FINDINGS, ACTIONS AND
OUTCOMES
• In this last step, document what happened
• In reality you will actually have been documenting the entire time so finalize the
documentation including the issue, cause, solution, testing, preventative measures, and any
other steps taken
• Documentation is extremely important; it helps in two ways. First, it gives closure to the
problem, for you and the user; it solidifies the problem and the solution, making you a better
trouble-shooter in the future.
• Second, if you or anyone on your team encounters a similar issue in the future, the history of
the issue will be right at your fingertips. Most technicians don’t remember specific solutions
to problems that happened several months ago or more.

You might also like