The troubleshooting method, and why the order of the steps matters

Why this matters

This is the single highest-value lesson in the course. Domain 5 is twenty-eight per cent of the exam, every question in it is a scenario, and CompTIA's six-step method is the framework those scenarios are written against. Questions routinely take the form "a technician has done X; what should they do next" — which is unanswerable without knowing the order and trivial with it.

It is also the lesson that pays in the job. The method is not bureaucracy; each step exists because skipping it produces a specific, recognisable failure. Technicians who work without it fix the wrong thing, fix the right thing without knowing why, or fix something and leave no trace that the next person can use.

Everything in the remaining eleven lessons of this domain is this method applied to a particular class of fault.

The lesson

The six steps in order, and what each one produces for the next

1. Identify the problem. Gather information, question the user, identify symptoms, determine what changed, and — where applicable — back up before making changes.
2. Establish a theory of probable cause. Question the obvious, and research if necessary.
3. Test the theory to determine the cause. If confirmed, determine the next steps. If 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.
6. Verify full system functionality and, where applicable, implement preventive measures.

And the seventh thing that is not a step but is always required:

1. Document the findings, actions and outcomes.

Each step hands something to the next. Identification produces symptoms; the theory is built from symptoms; the test confirms or discards the theory; the plan follows from a confirmed cause; implementation follows the plan; verification proves the implementation. Skip one and the next has nothing reliable to work from — which is why an exam question that describes a technician mid-sequence has exactly one correct next action.

Identifying the problem: the questions that separate a symptom from a story

Users report stories. "The internet is broken." "It just died." "It has been slow since Tuesday." The work of step one is converting the story into symptoms you can test.

The questions that do it:

• What exactly happens? Not "it does not work" — what appears on screen, what does not, what sounds are made.
• When did it start? A date is worth far more than "recently".
• What changed? New software, an update, a new cable, a house move, a power cut, a spill. This is the single most productive question in troubleshooting, and users volunteer the answer only when asked directly.
• Does it happen every time, or sometimes? Consistency is a major branch in the diagnosis.
• Who else is affected? One user, one machine, one room, everyone. This scopes the fault before any test is run.
• Can you show me? Watching the fault occur beats any description.

Two rules attached to this step. Ask about environmental and infrastructure changes, because a working machine that stopped after a building electrical change has told you where to look. And back up before making changes, which belongs in step one because after step five it is too late — this is examinable and it is also the thing that turns a bad day into a catastrophe.

Be careful with what a user says versus what a user did. "I did not change anything" is frequently sincere and wrong, so ask about specific events rather than for a confession.

Establishing a theory, and why the cheapest test comes before the likeliest cause

A theory is a specific, testable statement: "the display cable has failed", not "something is wrong with the monitor".

Question the obvious — CompTIA's own words, and the most commonly skipped instruction in the method. Is it plugged in, is it switched on, is the input correct, is the cable seated, is the user at the machine they think they are at. These are not insulting questions; they are high-probability, zero-cost ones.

The ordering principle is cost against probability. Prefer the test that eliminates the most possibility for the least effort, and that is often not the most likely cause:

• Swapping a display cable takes thirty seconds and eliminates one whole branch, so it comes before opening the machine even if the cable is not the favourite.
• Checking whether anyone else is affected is free and can eliminate the entire machine as a suspect.
• Rebooting is cheap and resolves a real proportion of transient faults — but it also destroys evidence, so on an intermittent fault the observation comes first.

Research is part of this step, and it is not an admission of ignorance. Vendor knowledge bases, error codes, and the organisation's own past tickets are where somebody has already met this fault.

Testing, escalating, and the point at which continuing costs more than escalating

A test must be capable of disproving the theory, or it is not a test. "I replaced the cable and it works now" confirms; "I replaced the cable and it still fails" disproves, and both are useful. A step that can only confirm tells you nothing when it does not.

Substitution is the strongest test available and this domain leans on it throughout: replace one component with a known-good equivalent, change one thing at a time, and put back anything that was not the cause. Changing two things at once and finding it fixed leaves you not knowing which mattered — which is a fix without a diagnosis, and the fault will return.

If the theory is disproved, establish a new theory or escalate. Escalation is a legitimate step, not a failure, and the exam treats it as the correct answer in specific circumstances:

• The task is outside your authority — a change to a production server, a firewall rule, a domain configuration.
• The task requires expertise you do not have, and experimenting risks damage.
• The fault is beyond your remit: a provider outage, a building electrical problem, a vendor defect.
• Continuing would breach policy, including anything involving data you should not access.
• You have spent the agreed time without progress.

A good escalation carries everything gathered so far — symptoms, what was tested, what was eliminated. Escalating a ticket that says "not working" wastes the next person's step one.

Documenting the outcome so the next person does not start from nothing

Documentation is the step most often skipped and the only one whose value accrues to somebody else, which is exactly why it is skipped.

What a useful record contains:

• The symptom as observed, not as reported.
• What was tested and ruled out. This is the part people omit and the part with the most value — the next technician does not repeat four dead ends.
• The cause, once established.
• What was done, precisely enough to be repeated, including part numbers, versions and settings.
• How it was verified.
• Anything left outstanding, including a temporary fix that will need revisiting.

Why it pays: recurring faults are recognised as recurring rather than rediscovered; a pattern across machines becomes visible; the next person starts from step three instead of step one; and a temporary workaround left in place is a known thing rather than a landmine.

The habit that makes it survivable is to record as you go rather than from memory at the end, because the dead ends are the first thing you forget and the most valuable thing you found.

Preventive measures belong here too, and they are part of step six: if the cause was dust, cleaning is the prevention; if it was a failing drive in an array, checking the others is; if it was a user action, showing them the correct method is. A fix that leaves the cause in place is a fix with a return date.