Structured Troubleshooting Methodology
Apply a repeatable diagnostic process instead of guessing, so faults are isolated with evidence and documented for the next technician.
- Certification
- CompTIA A+
- Recommended study time
- 4h 30m
- Status
- Not started
Recommended study time
About 4h 30m in total, measured from the material on this page. At your session length of 45 minutes that is 6 sittings.
- Read the lesson19 min
About 2,522 words at a careful technical reading pace.
- Second pass with notes11 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice2h
Labs, commands and configuration until you can do it unaided.
- Spaced review1h
4 short review sessions spread over the following weeks.
Learning objectives
- Apply the six-step troubleshooting process from symptom to documentation.
- Form a testable theory and choose a test that can disprove it.
- Record scope, evidence, actions, and results so an escalation is usable.
Start here
About 8 minutes of reading, in 10 short parts.
Good technicians are not people who happen to know every fix; they are people who follow a disciplined process that finds the real cause quickly and leaves proof of what was done. This lesson breaks that process into steps you can apply to any fault, however unfamiliar.
Where you meet it: Every support ticket, field repair, and outage call starts here, whether the symptom is 'my laptop is slow' or 'the whole floor lost network access'.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Think of a doctor diagnosing a patient. They do not guess a treatment and hope it works; they ask questions, run tests, form a hypothesis, and confirm it before treating. IT troubleshooting works the same way. Randomly trying fixes is like taking medicine for an illness you have not diagnosed: it might help by accident, but it might also make things worse and waste time.
The discipline is not about being clever, it is about being systematic. You gather facts first, narrow down possible causes using evidence, test the most likely one in a way that could prove you wrong, and only then apply a fix. Afterwards you write down what happened so the next person does not have to start from zero.
Key ideas
If you remember nothing else from this topic, remember these.
- The CompTIA six-step methodology is identify, theorize, test, plan and implement, verify and prevent, and document.
- Identifying the problem means establishing scope and recent changes before guessing at a cause.
- A theory of probable cause must be specific and testable, not a vague guess that cannot be disproven.
- Verification must be confirmed by the actual user's definition of working, not just the technician's observation.
- Documentation captures evidence and root cause, not merely the action taken, so future incidents resolve faster.
- Changing more than one variable during testing makes it impossible to know which change actually fixed the issue.
Diagnosing an intermittent Wi-Fi drop on one laptop
A worked example, step by step.
A user reports their laptop loses Wi-Fi every few minutes while other devices on the same network stay connected. You apply the full methodology rather than immediately reinstalling the OS.
- 01Step 1Identify the problem: ask when it started, whether it happens in every room, and whether a recent Windows update or driver change occurred.
- 02Step 2Establish scope: confirm a coworker's laptop nearby stays connected fine, narrowing the fault to this device.
- 03Step 3Form a theory: the Wi-Fi adapter's power management setting is allowing Windows to turn off the adapter to save power.
- 04Step 4Test the theory by opening Device Manager, viewing the adapter's Power Management tab, and checking whether 'Allow the computer to turn off this device to save power' is enabled.
- 05Step 5Confirm the setting is enabled, supporting the theory, and disable it as the plan of action.
- 06Step 6Implement the fix by unchecking the box and also disabling the wireless adapter's sleep setting in the advanced power plan settings (powercfg).
- 07Step 7Verify with the user over a real working session of at least 20 minutes that the connection no longer drops.
- 08Step 8Apply a preventive measure by noting the driver version and flagging it for review across similar laptop models in inventory.
- 09Step 9Document the symptom, theory tested, evidence, fix, and preventive note in the ticketing system.
Outcome: The laptop keeps a stable Wi-Fi connection, and the same power-setting fix is proactively applied to other units of the same model before they generate tickets.
Six-Step Troubleshooting Methodology
Worth keeping at hand while you work.
- Step 1
- Identify the problem: gather info, scope, recent changes
- Step 2
- Establish a theory of probable cause
- Step 3
- Test the theory to confirm or refute it
- Step 4
- Establish a plan of action and implement the solution
- Step 5
- Verify full system functionality with the user
- Step 6
- Document findings, actions, and outcomes
- Scope
- One user vs. multiple users vs. entire site
- Escalation
- Handing off when your access or expertise is exhausted
- Single-variable testing
- Change one thing at a time to attribute results
- Root cause
- The underlying condition causing the symptom
- Workaround
- A temporary bypass, not a permanent fix
- Preventive measure
- Action taken after the fix to stop recurrence
Common misunderstandings
What most beginners get wrong here.
A reboot that fixes the symptom means the ticket can close immediately.
A reboot is often a workaround; the root cause should still be identified if the symptom is likely to recur.
The technician deciding the issue is fixed is enough to verify.
Verification requires confirming with the user using their own definition of the problem being resolved.
Documentation is optional if the fix worked.
Documentation is required to prevent repeat investigation and to build a knowledge base for future incidents.
The first plausible cause found should be fixed immediately.
A theory should be tested before implementing a fix, so time is not wasted on an unconfirmed cause.
Scope only matters for network outages.
Scope matters for any issue since it distinguishes a single-device fault from a shared infrastructure problem.
Exam traps
How the question writers try to catch you out.
- Scenario questions often ask 'what should the technician do next', expecting the next step in the six-step order.
- Watch for distractors that skip straight to implementing a fix before testing the theory.
- A question may describe multiple simultaneous changes and ask what was done wrong, testing the single-variable principle.
- Exam wording often uses 'establish a theory of probable cause' verbatim, so know this exact phrase.
- Questions may test that verification means confirming with the user, not just technician observation.
Check yourself
Answer in your head first, then reveal. This is not scored.
What is the very first step of the CompTIA troubleshooting methodology?
Why must a theory of probable cause be testable?
What is the risk of changing two variables at once during a fix?
What is the final step of the methodology?
Who confirms that the issue is truly resolved?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
The CompTIA troubleshooting methodology is: identify the problem, establish a theory of probable cause, test the theory, establish a plan of action, verify full functionality and apply preventive measures, then document findings, actions, and outcomes. Each step produces evidence for the next.
Why It Matters
Random fixes create new problems, waste change windows, and destroy the evidence needed to find the real cause. A structured method also protects you politically: documented scope and tests show why a decision was made when an incident is reviewed.
How It Works
- Gather symptom, timing, scope, and recent changes before touching anything.
- Rank probable causes by likelihood and cost of testing, then test the cheapest discriminating one.
- Escalate or implement a plan, verify with the user, and document what was proven, not just what was done.
Where You See It
- Service desk tickets, field repairs, network incidents, change reviews, and post-incident reports.
Key Terms
- Scope
- How many users, devices, or services the symptom affects.
- Theory
- A specific, testable statement of probable cause.
- Isolation
- Changing one variable at a time to attribute a result.
- Verification
- Confirming with the user that normal function is restored.
- Root cause
- The underlying condition whose removal prevents recurrence.
Examples
- One user offline points at the endpoint; a whole floor offline points at shared switching or uplinks.
- Swapping a known-good cable tests the cable theory in seconds without buying hardware.
Common Problems
- Skipping scope questions
- Changing several things at once
- No verification with the user
- Notes that record actions but not evidence
How It Fails
- Multiple simultaneous changes make the successful one unidentifiable.
- An unverified fix returns as a repeat ticket and damages trust.
- Missing documentation forces the next technician to restart the diagnosis.
How to Troubleshoot
- Ask what changed and when the symptom started.
- Establish scope before depth.
- Test one variable, record the result, then decide the next test.
Practical Knowledge
- Ask the user what 'working' looks like so verification is objective.
- Preserve evidence, especially logs and error text, before rebooting.
Exam Coverage
- The six-step methodology
- Scope, theory, and testing
- Verification, prevention, and documentation
Interview Questions
- Walk me through how you diagnose an issue you have never seen.
- How do you decide when to escalate rather than continue?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Reading and courses
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Rewrite your last support ticket using the six steps explicitly.
- 02Practise stating a theory that a single test could disprove.