Lesson 2: The Troubleshooting Methodology as a Working Method

Why this level exists

A technician who guesses swaps parts at random, wastes time and can make the fault worse. A technician who follows a fixed method finds the cause faster and leaves a record that helps the next person.

CompTIA's 220-1201 objectives document sets out a six-step troubleshooting methodology. This level teaches it as your everyday working method.

One fact first: the exam does not test the methodology itself. It is taught here because it is how you should reason through the fault scenarios the exam does ask.

What the objectives document says about its status

The objectives document states that:

• Subject matter experts deemed the methodology "an effective best practice" that new job incumbents should be aware of and use.
• "The decision was made to not include it in the exam."
• It appears as part of the "competency standard" but "does not constitute a formal objective or part of the A+ certification exam."
• "There remains an emphasis on troubleshooting within the job role context."

What to do with this:

• Do not expect to be marked on naming or ordering the six steps.
• Do expect many "Given a scenario, troubleshoot..." items. Domain 5.0, Hardware and Network Troubleshooting, is 28% of the exam, the largest domain.

The six steps, in order

Learn these in CompTIA's wording:

1. Identify the problem.
2. Establish a theory of probable cause (question the obvious).
   • Research knowledge base/internet, if applicable.
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 and, if applicable, implement preventive measures.
6. Document findings/lessons learned, actions, and outcomes.

Two terms explained:

• Theory of probable cause: your best current explanation of the fault. It is a candidate, not yet a fact.
• Knowledge base: a searchable collection of known problems and fixes, kept by a vendor or by your own organisation.

A short way to hold the order: Identify, Theory, Test, Plan and implement, Verify, Document.

What you do at each step

Step 1: Identify the problem

Gather facts before touching anything.

• Ask the user what they see, when it started and whether anything changed recently.
• Observe the symptom yourself: lights, sounds, on-screen messages.
• Record the symptom in the user's words and in your own.

Step 2: Establish a theory of probable cause (question the obvious)

• List the possible causes, simplest first.
• Question the obvious: check the things that seem too simple to be wrong. Is it plugged in? Is it switched on? Is the correct input selected?
• Research the knowledge base or the internet if the symptom is unfamiliar.

Step 3: Test the theory to determine the cause

• Run one check that confirms or rules out the theory.
• Change one thing at a time, so you know which change had the effect.
• If the theory is ruled out, form a new one and test again. If you run out of theories, pass the problem to someone with more experience or access.

Step 4: Establish a plan of action to resolve the problem and implement the solution

• Decide what you will do and what the fix could affect, for example whether data should be backed up first.
• Then carry it out.

Step 5: Verify full system functionality and, if applicable, implement preventive measures

• Confirm that the whole system works, not only the part you fixed. Have the user confirm it too.
• Add a preventive measure where one makes sense, so the fault does not return.

Step 6: Document findings/lessons learned, actions, and outcomes

• Record what you found, what you did and what happened.
• This is the last step. Do not skip it: your notes become the knowledge base that someone researches in step 2 next time.

Worked example: "My monitor is blank"

A user reports that the desktop monitor shows nothing.

1. Identify. Ask: "When did it last work? Did anything get moved?" The user says the desk was rearranged this morning. Observe: the computer is running, and the monitor's power light is off.
2. Theory. Question the obvious: the monitor's power cable may have come loose during the move. Other candidates: the wall outlet or power strip is off, or the monitor has failed.
3. Test. Inspect the power cable at the back of the monitor. It is half out of its socket. The theory is confirmed.
4. Plan and implement. Plan: reseat the cable at both ends. No data is at risk. Do it.
5. Verify. The power light comes on and the picture appears. Ask the user to open their usual applications and confirm everything works. Preventive measure: route the cable so it is not pulled tight.
6. Document. Record: "Symptom: blank monitor, power light off. Cause: power cable dislodged during desk move. Action: reseated cable, rerouted for slack. Outcome: display working, confirmed by user."

Note what did not happen: nobody replaced the monitor before checking the cable.

Why it helps with Domain 5 scenarios

Domain 5 questions give you a symptom, such as a burning smell, a clicking drive or a paper jam, and ask for the likely cause or the next step. The methodology gives you a reasoning order for these:

• Read the scenario for the facts you are given (step 1).
• Prefer the simplest cause that fits all the facts (step 2).
• Prefer an answer that checks or confirms before one that replaces expensive parts (step 3).
• Be wary of answers that jump to a fix when nothing has been confirmed.

This is a way to reason, not a guarantee of a correct answer.

What the exam asks about this

• The methodology is not a formal objective, so do not rely on scoring marks by reciting it.
• Troubleshooting scenarios are heavily emphasised: Domain 5.0 is 28% of the exam.
• Use the six steps as your thinking order whenever a question describes a fault.

Key takeaways

• Six steps, in order: Identify; Theory (question the obvious, research if applicable); Test; Plan and implement; Verify and prevent; Document.
• Gather facts first, check simple causes first, change one thing at a time.
• Verify the full system, not only the repaired part.
• Documenting findings/lessons learned, actions, and outcomes is the final step.
• CompTIA lists the methodology as a best practice; it is not part of the exam, but troubleshooting scenarios are.