Maya's troubleshooting playbook

A plan for any problem

The troubleshooting methodology is a set of steps that works on any problem, from a printer to a server. Follow them in order:

• 1. Identify the problem.
• 2. Establish a theory of probable cause (question the obvious).
• 3. Test the theory to determine the cause.
• 4. Establish a plan of action, then implement the solution.
• 5. Verify full system functionality and, if it makes sense, add preventive measures.
• 6. Document what you found, the lessons learned, what you did and how it turned out.

Maya: It feels slow at first. It's faster than guessing three times.

Step 1: Identify the problem

Start by gathering facts, not fixes. Ask the user what they see and when it started. Ask what changed: a new roll of labels, an update, a moved cable. Try to make the problem happen again yourself. If anything you do might lose data, make sure it's backed up first. Only when you know what's really wrong do you move on.

You: Rosa, what's weird about it?

Rosa: It prints blank labels. It started right after I loaded the new roll.

Exam tip "What changed?" is the most useful question in IT.

Step 2: Establish a theory

A theory is your best guess about the cause. Question the obvious first: is it plugged in, turned on, loaded right? Simple causes are common and quick to check. If the problem is new to you, like an error code nobody has seen, research it in a knowledge base or on the internet, such as the maker's support site.

You: New roll, then blank labels. Theory: the roll is in backward.

Maya: That's a theory. Now prove it.

Step 3: Test the theory

Test your theory to find out whether it's the real cause. Flip the roll and print one test label. If the test confirms it, move on to a plan. If it doesn't, go back and form a new theory, or escalate to someone with more experience. Don't order parts for a cause you haven't proven.

You: flips the roll, prints A real label!

Rosa: Theory confirmed. You're getting good at this.

Exam tip Test failed? New theory (or escalate). Never fix a cause you haven't confirmed.

Step 4: Plan, then implement

Now establish a plan of action to fix the problem, then carry it out. A good plan thinks about side effects. Will the fix need a restart? Will people lose time? Does a manager need to approve it? Agree on a time with the user, then implement the solution. If the fix doesn't work, you can roll it back.

You: The update needs a restart. Rosa, can I do it at the 4 p.m. shift change?

Rosa: 4 p.m. is perfect. Thanks for asking!

Step 5: Verify, then prevent

Verify full system functionality: check that the whole job works for the user, not just the part you touched. Have Rosa print a real batch and make sure the labels scan at the dock. Then, if it makes sense, add preventive measures so the problem doesn't come back, like a label on the printer showing which way the roll goes.

Rosa: Twenty labels printed, all scanned. I'm putting your arrow sticker on every printer.

Ranger: sniffs the sticker. Approved.

Exam tip Verify = the user's real work succeeds. Prevent = it won't happen again.

Step 6: Document

Last, document findings, lessons learned, actions and outcomes in the ticket. Write the cause, what you did, and whether it worked. "Fixed" isn't enough. Good notes help the next tech who sees the same problem, and they build up the knowledge base that you'll research in step 2 next time.

You: Ticket notes: roll loaded backward after a change. Flipped it, tested, verified at the dock. Added roll-direction stickers.

Maya: That's a ticket I'd be proud of.

Six steps, always in order

CompTIA's troubleshooting methodology is a fixed order of steps. Following it stops you from guessing, wasting money or breaking something else:

• 1. Identify the problem.
• 2. Establish a theory of probable cause (question the obvious).
• 3. Test the theory to determine the cause.
• 4. Establish a plan of action and implement the solution.
• 5. Verify full system functionality and add preventive measures.
• 6. Document findings, actions and outcomes.

Exam tip Questions that ask what to do FIRST or NEXT are really asking which step you are on.

Step 1: identify the problem

Gather facts before you touch anything. Ask the user what they see and what changed before it started. Try to make the problem happen again. When Rosa says the label printer 'acts weird,' you ask what she sees and when it began. Ordering a new print head right away is a fix aimed at a cause nobody has found yet.

Exam tip First move on a new ticket = ask questions. Not replacing parts, not closing the ticket.

Steps 2 and 3: form a theory, then test it

A theory of probable cause is your best guess. Question the obvious first: is it on, plugged in, charged, loaded right? Mr. Barkley's black monitor gets a cable and power check before anyone orders a graphics card. If an error is new to you, like scanner code E-47, research the maker's knowledge base or the internet. Then test the theory: flip the label roll and print one test label. If the test fails (a fresh battery and the scanner still won't start), form a new theory or escalate.

Exam tip A theory isn't the cause until a test proves it.

Step 4: plan the fix, then do it

Once the test proves the cause, plan how to fix it and think about the effects on people. A fix that needs a restart will stop Rosa's team from printing shipping labels, so you agree on a restart time with her, then apply the update. Big changes may also need approval. Restarting in the middle of a shipping rush is the tempting shortcut that causes a second problem.

Exam tip The plan covers the side effects: downtime, who is affected and when.

Steps 5 and 6: verify, prevent, document

Verify full system functionality: check that the whole job works for the user, not just the part you fixed. Rosa prints a full batch, and the labels scan at the dock. Then add preventive measures so it doesn't come back, like a charging dock and a shift-end check for scanners. Last, document the cause, what you did, the outcome and the lesson learned. A ticket that only says 'fixed' is not documented.

Exam tip Verify comes before document, so your notes can say the fix worked.