Getting locked out of your email or having a printer jam right before a deadline can stop your entire day. Without a structured approach, you might randomly click buttons, make the problem worse, and waste hours. The troubleshooting methodology gives you a simple, repeatable seven-step process that IT professionals use to solve problems quickly and reliably, and it is a key part of the FC0-U71 exam.
Jump to a section
A simple way to picture Troubleshooting Methodology
A head chef at a busy restaurant doesn't start cooking randomly when a dish comes back wrong. They follow a method.
Imagine the chef gets a complaint: 'The pasta is too salty.' The chef doesn't immediately dump in more cream or start a new pot of water. First, they identify the symptom: salty pasta. Then, they establish a theory of probable cause. Did the new line cook add salt twice? Did the recipe change? Did the pre-made sauce arrive with extra sodium? The chef gathers evidence - they taste the sauce, they check the recipe card, they ask the cook.
Next, they test their theory. The chef thinks, 'If the sauce is too salty, then a new batch of sauce should fix it.' They make a small, fresh batch of sauce. The chef adds his fresh sauce to a new portion of pasta and tastes it. The salt level is correct. The theory is proven. The chef has isolated the cause. He implements the solution: use only the new sauce for the remainder of the service.
Finally, the chef verifies the fix works by serving the corrected dish to another guest and getting a positive review. He documents the issue on the kitchen clipboard: 'Salty pasta - caused by salty pre-made sauce. Action: switch to in-house sauce.' If the problem returns, the chef has a documented starting point. This whole process - identify, theorise, test, plan, implement, verify, document - is the troubleshooting methodology. The chef doesn't guess; he investigates.
The CompTIA Tech+ exam defines troubleshooting as a methodical process used to solve technical problems. It is not about guessing or luck. It is a step-by-step guide that ensures you fix the right problem the first time without causing more damage.
The official CompTIA troubleshooting methodology consists of seven steps. You need to know them in order for the exam.
Step 1: Identify the problem. This is the first and most critical step. You must gather information about what is actually wrong. This includes asking the user specific questions like 'What were you doing when it stopped working?' and 'Has this happened before?'. You also need to identify the scope of the problem. Is it a single computer or the whole network? Write down the symptoms. A symptom is what the user observes, like 'the screen is black' or 'the program is frozen'.
Step 2: Establish a theory of probable cause. Based on the symptoms, you ask yourself 'What could most likely cause this?' Do not jump to conclusions. Start with the most obvious and simple causes first. For a computer that won't turn on, the most probable cause is that it is unplugged or the power cable is loose. A theory is your best guess, but it must be testable.
Step 3: Test the theory to determine the cause. You now prove or disprove your theory. If your theory was 'the power cable is loose', you check the cable. If the computer turns on when you plug it in, your theory is correct and you have found the cause. If the computer still doesn't turn on, your theory is wrong, and you must go back to Step 2 and establish a new theory.
Step 4: Establish a plan of action to resolve the problem and identify potential effects. Before you start fixing things, you need a plan. What exactly will you do? For a loose power cable, the plan is to 'secure the cable and restart the computer'. Crucially, you must consider potential negative effects. If you plan to replace a hard drive, what happens to the data? You need a backup first.
Step 5: Implement the solution or escalate as necessary. This is where you do the fix. If the fix is simple, you do it yourself. For example, plugging in the cable. However, sometimes the problem is beyond your authority or skill level. For example, if you discover a server is broken, you cannot replace it yourself. You must escalate the problem to a senior technician or the appropriate team. Escalation is a formal process of passing the problem to someone else.
Step 6: Verify full system functionality and, if applicable, implement preventative measures. After you apply the fix, you must confirm that the problem is gone AND that nothing else broke. If you fixed a password issue, you should ask the user to log in successfully. If you replaced hardware, you run a test. Then, you implement preventative measures to stop the problem from happening again. For example, if a user's computer crashed because the hard drive was full, you set up automatic disk cleanup tasks.
Step 7: Document findings, actions, and outcomes. This is the step beginners often skip, but it is crucial. You write down what the problem was, what caused it, and exactly what you did to fix it. This creates a knowledge base for the future. Next time someone has the same problem, another technician can search your notes and fix it in minutes.
This methodology replaces the old, ineffective 'trial and error' approach where people just try random things. It saves time, prevents repeat problems, and creates a professional standard of work. For the exam, memorise these steps in order. The exam will present you with a scenario and ask you 'What should the technician do next?' Your answer should always follow the logical order of this process.
Identify the Problem
The technician gathers information about the problem. This includes asking the user questions, checking system logs, and determining the scope (how many users are affected). The goal is to get a clear, detailed description of the symptoms.
Establish a Theory of Probable Cause
Based on the symptoms, the technician forms a best guess about what is causing the issue. This theory must be simple and testable. Example: 'The computer won't turn on. The most probable cause is a disconnected power cord.'
Test the Theory to Determine the Cause
The technician performs a test to confirm or disprove the theory. If the theory is confirmed, they have found the actual cause. If not, they return to step 2. Example: 'Check if the power cord is plugged into the wall and the computer.'
Establish a Plan of Action
Before doing any work, the technician creates a specific plan. This includes the steps to fix the problem and identifying potential negative effects, such as data loss or system downtime.
Implement the Solution or Escalate
The technician carries out the plan from step 4. If the fix is beyond their skill or authority, they escalate the problem to a higher-level technician or team. Example: 'Plug in the power cord securely and restart the computer.'
Verify Full System Functionality
After the fix is applied, the technician checks that the original problem is completely resolved and that the whole system is working correctly. They also implement preventative measures to stop the problem from recurring.
Document Findings, Actions, and Outcomes
The technician writes down what the problem was, what caused it, what was done to fix it, and the final outcome. This documentation is stored for future reference and for other technicians to use.
Sarah works as a helpdesk technician for a medium-sized insurance company. She receives a call from a panicked user named David. David says, 'My spreadsheet is gone! I was working on it for two hours, and now it's not on my desktop!'.
Sarah does not panic. She follows the methodology.
Step 1: Identify the problem. Sarah asks David specific questions: 'What was the file name?', 'What program were you using?', 'Did you save it?', 'Did you move it to a different folder?', 'Did you accidentally close the program?'. David says the file was called 'Q4_Budget.xlsx' and that he was using Excel. He says he 'saved it earlier' but doesn't remember where. Sarah notes the symptom: a file that is not where the user expects it to be.
Sarah thinks about common causes for missing files. Theory 1: David saved it to a different folder (e.g., Downloads or Documents). Theory 2: David moved or deleted the file accidentally. Theory 3: The file was closed without saving recent changes.
Step 3: Test the theory. Sarah starts with Theory 1, the simplest. She asks David to open Excel and check the 'Recent Files' list on the File menu. David sees the file in the list. Sarah asks him to click on it. The file opens! The theory is correct: the file was saved earlier, but David saved it to the 'Documents' folder instead of the Desktop.
Step 4: Establish a plan of action. Sarah decides to show David how to pin the file to the taskbar so he can always find it quickly. She also considers the potential effect: if David doesn't learn where his files are saved, he will lose them again.
Step 5: Implement the solution. Sarah guides David through the steps to pin the file. She also shows him how to use the 'Save As' function to always save to his Desktop. She does not escalate, as this is a simple user-training issue.
Step 6: Verify full system functionality. Sarah asks David to close Excel and re-open the file from the Desktop shortcut they just created. It works. She also asks him to check if any other files are missing. He says no.
Step 7: Document findings. Sarah opens her ticketing system and writes: 'User couldn't find Q4_Budget.xlsx. Cause: User saved file to Documents instead of Desktop. Action: Guided user to find file via Recent Files, then pinned file to taskbar. Outcome: Verified. Preventative measure: Trained user on Save As location.'
This documentation helps if David calls again. It also allows Sarah to see a pattern: if many users are losing files, the company might need to change its default save location. The methodology turns a chaotic 'lost file' situation into a resolved, documented outcome.
The FC0-U71 exam tests your ability to recall and apply the troubleshooting methodology. Expect at least three to five questions directly on this topic. These are not trick questions, but they require you to know the exact order and definition of each step.
Common question types include:
Scenario-based questions: The exam will present a short story about a technician dealing with a problem. It will then ask 'What should the technician do NEXT?' or 'Which step of the methodology is the technician currently performing?'.
Sequencing questions: The exam might list the seven steps in a random order and ask you to select the correct sequence from a multiple-choice list.
Definition matching: The exam might describe a step (e.g., 'A technician writes down the steps taken to resolve a printer jam') and ask you to identify the step number (in this case, Step 7: Document findings).
The main trap on the exam is the 'skip ahead' trap. The distractors (wrong answers) will often describe useful actions that are not in the correct order. For example:
The scenario: 'A user reports that their computer won't connect to the internet. The technician has identified the problem and established a theory that the network cable is unplugged.' Question: 'What should the technician do next?' Trap answer: 'Immediately plug in the network cable.' Correct answer: 'Test the theory to determine the cause (e.g., check if the cable is unplugged).'
The exam wants you to verify before you act. Do not jump from theory straight to implementation. You must test first.
Key concepts to memorise:
The seven-step order: 1. Identify the problem. 2. Establish a theory of probable cause. 3. Test the theory to determine the cause. 4. Establish a plan of action. 5. Implement the solution or escalate. 6. Verify full system functionality. 7. Document findings.
Escalation: Know that escalation is part of Step 5. You escalate when the problem is too complex, dangerous, or requires more authority.
Preventative measures: Part of Step 6. This is about stopping the problem from recurring. A simple example is setting up automatic updates.
Documenting: Step 7 is not optional. It is the final step and creates a knowledge base.
Probable cause vs. Actual cause: 'Probable cause' is your initial best guess. 'Actual cause' is what you prove in Step 3. The exam will use this language.
A specific trap to watch for: the exam might present a scenario where the technician is already implementing a solution that is not working. The question asks 'What should the technician do?' The correct answer is: go back to Step 2 (establish a new theory) and test again. Do not keep trying the same broken fix.
Also, learn the difference between 'plan of action' and 'implement the solution'. The plan is created in Step 4. The actual doing happens in Step 5. The exam will test this separation.
The troubleshooting methodology has seven specific steps that must be followed in the exact order: Identify, Theory, Test, Plan, Implement, Verify, Document.
Always test your theory of probable cause before you implement a solution; never skip directly from theory to implementation.
If your test disproves your theory, you must return to step 2 to establish a new probable cause.
Documentation is the final step and is just as important as the fix itself, because it creates a reusable knowledge base.
Escalation is a formal part of step 5 and is used when the problem requires more expertise or authority than you have.
Verifying full system functionality means confirming the original problem is fixed AND that no other issues were introduced by the fix.
These come up on the exam all the time. Here's how to tell them apart.
Symptom
What the user reports or sees
Example: 'The printer is not printing'
Sometimes misleading or incomplete
Cause
The underlying technical reason
Example: 'The printer paper tray is empty'
Discovered through testing
Theory of Probable Cause
An initial best guess based on symptoms
Made before any testing
May be wrong and require a new theory
Actual Cause
The proven reason after testing
Identified in step 3 of the methodology
Always accurate by definition
Plan of Action
Created in step 4
A written or thought-out approach
May include multiple sub-steps or rollback plans
Implementation
Performed in step 5
The actual execution of the plan
May involve escalation if necessary
Verification
Step 6: Checking the fix works
Focuses on the immediate system
Includes preventative measures
Documentation
Step 7: Recording what happened
Focuses on future reference
Is the final step after verification
Mistake
Troubleshooting means trying the most obvious fix first, like restarting the computer.
Correct
Troubleshooting starts with identifying the problem and gathering information. Restarting is a potential test or solution, but only after you have established a theory. The order is important.
Many users only know 'turn it off and on again' as a fix. They learn this from personal experience and mistakenly think it is the entire job. The exam tests the difference between a random fix and a methodical process.
Mistake
The steps must be followed exactly once, in a strict linear order, and you cannot go back.
Correct
The methodology is a cycle. If your test disproves your theory, you must go back to step 2 to form a new theory. You iterate until you find the actual cause.
Textbooks present the steps as a list, which can make it seem rigid. Beginners think you must finish all seven steps, even if the first theory is wrong. The exam tests your ability to loop back.
Mistake
Documentation is just a formality for the ticketing system and doesn't help the current problem.
Correct
Documentation is essential for the current problem (for future reference) and for the organisation. It helps other technicians solve similar problems faster. It proves work was done.
New technicians are often focused on speed. They want to solve the incident and move on. They see documentation as a chore, not a tool. The exam emphasises its importance as a final verification step.
Mistake
Escalation means you have failed and should be embarrassed.
Correct
Escalation is a standard professional process. It is part of the methodology to recognise when a problem is beyond your scope of control or knowledge. It protects the company from mistakes.
People naturally want to solve problems themselves to prove their competence. Admitting you cannot fix something feels like losing. The exam tests the proper procedure for escalation, not the feeling.
Mistake
Identifying the problem just means asking 'What's wrong?' once.
Correct
Identifying the problem is a detailed investigation. You ask multiple questions (who, what, when, where, and how). You also check for changes (has any new software been installed?). You look at logs and error messages.
Beginners assume the user's description is complete and accurate. Users often give vague answers like 'it's broken'. The exam tests the comprehensive approach to problem identification.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes. The exam will ask scenario-based questions where you must know which step comes next. The exact order is: Identify, Theory, Test, Plan, Implement, Verify, Document.
You go back to step 2 to establish a new theory of probable cause. You do not jump to step 4 or try a random fix. You keep testing until you find the actual cause.
Restarting is a common solution, but it comes after you have identified the problem and theorised that a software glitch is the cause. It would be part of Step 3 (testing the theory) or Step 5 (implementing the solution).
Escalation means formally passing the problem to a different person or team who has the required expertise, tools, or authority to solve it. It is part of Step 5.
Documentation creates a record so that the same problem can be solved quickly in the future. It also helps management identify recurring issues and improve systems. It is Step 7.
A symptom is what the user experiences, like 'the screen is blue'. The cause is the underlying reason, like 'a faulty video driver'. The methodology helps you move from symptom to cause.
You've finished Troubleshooting Methodology. Continue through the FC0-U71 study guide to build a complete picture of the exam.
Done with this chapter?