A user calls and says "my computer is broken." That's all you get. Where you go next separates a technician who fixes problems quickly from one who swaps parts at random and hopes. CompTIA's troubleshooting methodology is the repeatable path from that vague complaint to a documented fix. The 220-1201 objectives list it as a best practice rather than a tested objective, but the Hardware and Network Troubleshooting domain (28% of Core 1) is built on scenarios that reward the same habits.
The six steps, in order
The order is the point. Each step feeds the next, and skipping ahead is how technicians replace parts that were never broken.
- Identify the problem.
- Establish a theory of probable cause (question the obvious).
- Test the theory to determine the cause.
- Establish a plan of action to resolve the problem and implement the solution.
- Verify full system functionality and, if applicable, implement preventive measures.
- Document findings, lessons learned, actions, and outcomes.
Two habits run through all six: gather information before you act, and confirm your work before you close the ticket. Everything below is those two habits applied step by step.
Step 1 identifies the problem before anyone touches a part
Talk to the user first, open questions before narrow ones: what were you doing, has it happened before, what changed? Ask about the environment too, not just the machine. A workstation that lost the network right after an office rewiring points away from its own hardware. Then check the system's own records: event logs, error codes, recent updates. A specific error code beats a paragraph of description because you can look it up. Reproduce the problem if it is safe to, because a problem you can trigger on demand is one you can test and later prove fixed.