The 6-step CompTIA A+ troubleshooting methodology, in plain English

What are the six steps

CompTIA publishes them in the front matter of the 220-1201 objectives document, before domain 1 starts. The 220-1202 document does not repeat them. There is no objective number attached and CompTIA says outright that the list is not a formal objective or part of the exam. The order is still useful because each step checks a different kind of mistake before you move on. Skipping step 2 can send you toward the wrong fix. Skipping step 5 can let a problem return unnoticed. The bold text below follows CompTIA's six-step wording; the text after it is our plain-English explanation.

1. Identify the problem. Talk to the user, gather symptoms, check what changed.
2. Establish a theory of probable cause (question the obvious). Research knowledge base/internet, if applicable.
3. Test the theory to determine the cause. Use a controlled test to confirm or disprove the theory before choosing the fix.
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. Confirm the fix across the user's full workflow.
6. Document findings/lessons learned, actions, and outcomes. Write it down for the next tech and for the user.

If you have seen a seven-step version of this list, you were looking at Network+. For A+, six is what CompTIA publishes, and it is not tested.

What are the seven Network+ steps, and how are they different

Network+ N10-009 objective 5.1, "Explain the troubleshooting methodology," is a formal exam objective. The outline below paraphrases its seven steps and sub-bullets; the objectives PDF contains the full hierarchy.

1. Identify the problem. Gather information, question users, identify symptoms, determine if anything has changed, duplicate the problem if possible, and approach multiple problems individually.
2. Establish a theory of probable cause. Question the obvious and consider multiple approaches: top-to-bottom or bottom-to-top through the OSI model, or divide and conquer.
3. Test the theory to determine the cause. If the theory is confirmed, determine the next steps to resolve the problem. If it is not, establish a new theory or escalate.
4. Establish a plan of action to resolve the problem and identify potential effects.
5. Implement the solution or escalate as necessary.
6. Verify full system functionality and implement preventive measures if applicable.
7. Document findings, actions, outcomes, and lessons learned throughout the process.

Three differences matter. Network+ splits planning and implementing into two steps, and its plan step asks you to identify potential effects. It names escalation inside the test and implement steps. And its theory step names the OSI-layer approaches. The rest of this post walks the six A+ steps; on Network+, learn the seven.

Step 1 and 2: how do you identify the real problem

Consider a hypothetical dental-office call: "The check-in laptop is slow." That is a symptom, not a problem. Identify means asking what slow looks like. When did it start. What did you change recently. Did anything else change at the same time. Cheap questions, expensive answers.

Once you have symptoms, it is easy to anchor on an exciting answer, such as a rare driver bug or an obscure registry key, and miss a simpler explanation. Check the simplest evidence-backed theory first. If a laptop slowed down last Tuesday and an update landed that day, the update is one theory to test, not a confirmed cause.

Steps 3 and 4: why should you test before you fix

Testing the theory means you confirm the cause before you commit to the fix. On the dental office laptop, Update History shows that an update landed Tuesday afternoon, matching the user's timeline. That timing strengthens the theory, but it does not confirm the cause by itself; use a controlled, reversible test or another comparison before calling it confirmed.

If the test fails, do not double down. Form a new theory or escalate. Defending a failed theory wastes time and can add risk. The plan of action follows from a confirmed cause. If a controlled test confirms the update as the cause, plan the smallest approved, reversible response. That might be a vendor-supported rollback or workaround, with recovery steps, documentation, and a plan to apply the corrected update.

Step 5: how do you actually verify the fix

Verify full system functionality is easy to rush, but it is where the ticket moves from a symptom check to a full workflow check. The dental office laptop boots faster now, sure, but does the check-in app still talk to the practice management server. Does the receipt printer still work. Did the rollback flip the network adapter into a weird state. You confirm the whole workflow, not just the symptom.

Preventive measures sit inside this step. If the bad update will keep trying to install, you hold it. If the user keeps clicking the same broken shortcut, you fix the shortcut. The point is the same problem should not visit twice for the same root cause.

Step 6: why does documentation help the next tech

The final step, "Document findings/lessons learned, actions, and outcomes," creates a record the next person may need. In the hypothetical logistics firm, clear documentation would matter because several technicians could handle the same equipment. A useful note might say, "bad switch port 14, moved to port 17, port 14 flagged for replacement, do not put printer back on 14."

Documentation is also the easiest step to talk yourself out of when the fix took two minutes. Write it anyway. A brief, clear note can turn a one-off save into something the next person can repeat.

Why do help desks care about the order

Closing a ticket is not the same as showing that the underlying problem is resolved. The methodology helps you test the fix, reduce repeat work, and leave the next technician a usable record.

A ticket system may mirror part of this flow with fields for the problem, action taken, resolution, and notes. Theory, testing, and verification may live in notes rather than dedicated fields, but they still help show whether the fix holds.

What does this look like in our platform

The Help Desk Simulator uses the methodology in two ticket flows. On current scripted-reply tickets, each authored reply is tagged to a step. Theory replies stay hidden until the simulator has counted at least two reply picks or unique tool uses in combination, and later tagged replies use prerequisite gates that skip steps the ticket does not author. Hands-on tickets instead follow an authored chain of action checkpoints. On scripted-reply tickets, the top grade requires the closing reply with no sub-optimal or incorrect picks and no hints; hands-on tickets are graded from checkpoint completion.

If you are tracking toward the A+, the A+ track page summarizes every domain and links to the detailed Core 1 and Core 2 objective maps. On Core 1, domain 5, Hardware and Network Troubleshooting, carries the most weight at 28 percent of 220-1201. On Network+, the methodology is objective 5.1 on the Network+ objectives page.

What does the methodology look like on a hardware ticket

Run the same six steps on a hardware ticket and the order is even more obvious. A user at the dental office reports a monitor that flickers every few minutes. Identify the problem: when did it start, has the cable been moved, are other monitors on the same desk affected. Form a theory: cable, port, GPU output, or monitor, ordered by the evidence and by the least disruptive safe test. Test the theory with a known-good cable. If the flicker stops, the cable becomes the leading cause; verify long enough to rule out an intermittent return before calling it confirmed.

Plan and implement the solution: give the user a known-good spare cable, then order a suitable replacement under the site's normal change process. Verify the whole workflow: does the monitor stay stable long enough to rule out an intermittent return, and does the second monitor still work normally. Document the result: note the cable model and length, what changed during the test, and whether the symptom returned. The next technician now has the cable history without treating one successful swap as conclusive proof.

Where should you go next

The methodology has no objective number. The formally tested troubleshooting content on Core 1 is domain 5, which runs from 5.1 through 5.6: motherboards, RAM, CPUs and power (5.1), drives and RAID (5.2), video, projector and display issues (5.3), mobile devices (5.4), networks (5.5), and printers (5.6). There is no 5.7. You can use the six-step methodology as a practical framework across those objectives, but CompTIA does not formally test the methodology or its order on A+.

About the authors

Nick Miller

Founder and Lead Author

IT Service Center Manager and former CTE / IT teacher. Owner of Revtek IT Solutions.

LinkedIn ↗

R

Revy

Study buddy · AI co-author

Nick directs these posts, AI helps draft them, and Nick reviews every post before it goes live. If you spot an error, tell us and we will fix it. We disclose this here because it is the right thing to do. See the AI Policy for the full stance.