CompTIA Troubleshooting Methodology

The Six-Step Methodology (Objective 5.1)

CompTIA codifies troubleshooting as a 6-step process that appears on both the Core 1 (220-1201) and Core 2 (220-1202) exams. The wording on the objectives is precise, and exam items reward you for the exact order. Before you start, CompTIA expects two prerequisites on every job: always consider corporate policies, procedures, and impacts before implementing changes, and back up critical data before making changes 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?).
• Conduct external or internal research based on symptoms — 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, 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) and back up the PST/profile. 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 — 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 — exactly the trap PBQs set.

Why Each Step Matters

Identifying the problem is the step technicians most often shortcut, and it is the one CompTIA weights most heavily in scenario items. 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. The objective 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 Exam Traps

• "What should you do FIRST?" is almost always identify the problem / gather information, not a hardware swap or reboot.
• Backing up data belongs to the identify/plan phase — 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.
• Steps 5 and 6 are easy points: candidates forget that verify and document are mandatory even after a trivial fix.