Following a Methodical Order of Elimination

Approaching a problem methodically is efficient and cost-effective . Most problems can be categorized and eliminated with careful troubleshooting.

While troubleshooting, you should generally check for problems in the following order:

User - related problems
Software-related problems
OS-related problems
Hardware-related problems

Statistically, most problems are user-, software-, or OS-related. Also, this order usually represents the least expensive to the most expensive repairs . If you approach your problem-solving in this order, you will be as efficient and cost-effective as possible.

User-Related Problems

Check for user-related problems while gathering information, duplicating the problem, and trying quick fixes. These include incorrectly set preferences, inadvertent errors, incompatibilities, and incorrect assumptions.

Software-Related Problems

Software can cause symptoms that look like hardware problems. Always check for software problems before assuming the problem is hardware-related. Report bugs if you find them (this is an instance where your notes will be helpful).

OS-Related Problems

You can identify OS-related problems from general symptoms that affect all applications, or from specific symptoms, such as problems that prevent the startup process from completing. Most of this lesson focuses on OS-related problems.

Hardware-Related Problems

When you're convinced that the problem is not user-related, software- related, or OS-related, you should troubleshoot it as a hardware issue. Hardware problems are beyond the scope of this book; Apple's Knowledge Base at www.apple.com/support is an invaluable resource, as is the Peachpit Press book "Apple Training Series: Desktop and Portable Systems, Second Edition."

If you isolate the problem to hardware, and you are an Appleauthorized service technician, follow the appropriate service procedures. Otherwise, contact an Appleauthorized service provider for repairs.

Troubleshooting Systematically

Troubleshooting is a process. If you go about it systematically, you'll greatly improve your chances of success. Even in those instances where you can skip a step, it's important to evaluate the process in its entirety to ensure that you are not missing something obvious.

The following illustration shows the main steps of the troubleshooting process. The first row includes steps that help you assess the problem, the second row shows steps where you identify the cause and troubleshoot so that you understand it completely, and the third row is about fixing the problem and wrapping up the issue.

As you go through the process, keep in mind:

The two goals of troubleshooting: fix the problem properly, and fix it quickly.
Tasks such as keeping notes that are important in every stage.
You are troubleshooting to eliminate potential causes and determine appropriate solutions. When you find the answer, you can move on to the next stage.

Every support person uses some type of troubleshooting process, and many organizations formalize their process to ensure that their technicians don't inadvertently skip troubleshooting steps. The troubleshooting process in the following illustration is used by the AppleCare support group , in order to make sure all issues are properly handled and accurately tracked. Your organization may have a similar process, and you may already be familiar with steps in this process flowchart.

The flowchart describes a series of loops you perform until you return the system to normal operation. Let's say you're a desktop support technician called to work on a malfunctioning computer. According to the flowchart, the first step is to gather information. You immediately encounter a decision point: was it a simple problem, and did gathering information alone resolve the problem? If it doesn't, you then verify the problem, that is, you see if you can reproduce it, and you try a quick fix. (You can skip the on-site service decision, since you already have the computer in front of you.) Let's say you think you have identified the problem, so you skip to repair or replace. (In a software context, this choice can be stated as "troubleshoot or reinstall.")

After completing the repair (often a quick fix is a repair), you ask yourself if the problem is resolved. No? Then you loop back to trying quick fixes. You may try a number of quick fixes before either resolving the problem or deciding that no more quick fixes apply and you need to go on to running diagnostics. You may realize that you have exhausted your knowledge and need to research. You may decide that it is time to escalate the problem to a senior technician. Or, you may determine that the problem is fixed and enter the documentation/notification stage.