CompTIA Troubleshooting Methodology

The Six-Step Methodology (a Competency Standard)

The V15 Core 1 (220-1201) objectives describe troubleshooting as a 6-step methodology, printed as a "competency standard" rather than a formal objective. CompTIA's note says the methodology itself will not be tested, while troubleshooting within the job role context remains a focus, so treat the steps as the way to work a problem, not as a list to recite. The Core 2 (220-1202) objectives do not print the methodology; its troubleshooting sits in domain 3, Software Troubleshooting. CompTIA's own troubleshooting guidance adds two habits when you plan a fix: follow your change-management procedures and get any approval you need, and back up data that the fix could put at risk so a fix never destroys the user's work.

Step 1 — Identify the Problem

• Gather information from the user: What happened? When did it start? What were you doing when it failed?
• Question the user about environmental or infrastructure changes (new software, an OS update, a moved desk, a power outage).
• Inquire regarding changes to the computer — recently installed drivers, hardware swaps, or pushed patches.
• Reproduce the problem if possible, and review system, application, and security logs in Event Viewer.
• Approach the problem with empathy — do not blame the user.

Step 2 — Establish a Theory of Probable Cause

• Start with the most probable, simplest cause first (the "question the obvious" rule: is it plugged in, powered on, cable seated?).
• Research the knowledge base/internet, if applicable — vendor knowledge base, manufacturer documentation, or your ticketing history.
• Hold multiple candidate theories; do not fixate on the first idea.

Step 3 — Test the Theory to Determine the Cause

• Run a targeted, low-risk test that confirms or rejects the theory.
• If confirmed, move to Step 4 to plan the resolution.
• If not confirmed, re-establish a new theory or escalate to a higher tier — do not improvise a fix.

Step 4 — Establish a Plan of Action and Implement the Solution

• Build a plan that fixes the root cause, weigh the impact on other users/systems, back up data at risk, get any approval the change needs, and refer to vendor documentation for the exact procedure.

Step 5 — Verify Full System Functionality

• Confirm the original symptom is gone, test related features, and implement preventive measures (patching, driver updates, scheduled backups) where applicable.

Step 6 — Document Findings, Actions, and Outcomes

• Record symptom, cause, resolution, and any preventive steps in the ticket/knowledge base — required on every ticket.

Quick-Reference Order Table

Worked Scenario

A user says Outlook "stopped working this morning." A weak technician reinstalls Office immediately. The correct play: Step 1 — ask what changed (the user mentions a Windows update overnight). Step 2 — theory: the update broke the mail profile. Step 3 — test by launching Outlook in safe mode (outlook /safe); it opens, confirming a profile/add-in fault. Step 4 — back up the PST/profile, then disable the offending add-in. Step 5 — verify send/receive and calendar. Step 6 — log it. Reinstalling first would have been a Step-4 action taken before any theory was tested.

Why Each Step Matters

Identifying the problem is the step technicians most often shortcut. A reported symptom ("the Internet is down") is rarely the real fault ("the Wi-Fi adapter is disabled"). Gathering precise information, learning what changed, and reproducing the failure converts a vague complaint into a testable hypothesis. This is also where you decide whether the issue is even in your scope or must be escalated under company policy.

Establishing a theory is governed by Occam's razor: the simplest explanation that fits the symptoms is the most probable. A printer that "won't print" is far more likely out of paper or offline than suffering a fried formatter board. CompTIA's phrase "question the obvious" is a direct hint that the simplest causes — power, cables, switches, settings — come first.

Testing the theory must be a discrete, reversible action that yields a clear yes/no. Booting into Safe Mode, swapping a cable for a known-good one, or pinging a gateway are good tests because each one isolates a single variable. A test that changes three things at once tells you nothing about which one mattered.

Planning and implementing is where impact analysis lives: a fix that requires a reboot in the middle of the workday, or one that touches a shared server, must be scheduled and communicated. Verifying full functionality prevents the classic callback where the original issue is fixed but a side effect (no audio, no printer mapping) was introduced. Documentation turns one technician's work into institutional knowledge and is the evidence trail an audit relies on.

A Second Scenario

Three users on one floor lose network access. A novice resets each PC. The methodology says otherwise: identify — all three sit on the same switch, so the common factor is infrastructure, not the PCs. Theory — the access switch or its uplink failed. Test — check the switch's link lights and ping it; the uplink port is dark. Plan — replace the patch cable to the distribution switch, considering that the swap briefly drops the segment. Verify — all three regain access and can reach shared drives. Document — note the bad cable and the port.

Recognizing the common element among affected users is a recurring Domain-5 reasoning pattern.

Common Troubleshooting Traps

• In a troubleshooting scenario, start by identifying the problem / gathering information, not with a hardware swap or reboot.
• Backing up data that a fix could put at risk belongs to the plan step, before you implement — losing data because you skipped it is a policy failure.
• After a failed test of theory, the next step is a new theory or escalation, never "document and close."
• When multiple users share one symptom, look for the common element (switch, server, DHCP scope, recent patch) before touching individual devices.
• Do not skip Steps 5 and 6: verify and document even after a trivial fix.