Using the CompTIA A+ Troubleshooting Method on Software Bugs

When I studied for CompTIA A+, I memorized the six step troubleshooting method because it was on the exam. I expected to forget it the week after. Instead it became the way I debug code. The method was written for hardware and operating systems, but every step maps cleanly onto a broken Python script, a failing API call or a web page that suddenly renders blank.

Here are the six steps as CompTIA lists them, and how I use each one when software misbehaves.

1. Identify the problem

The A+ material tells you to gather information, question the user, identify symptoms and determine what changed. For code, that means collecting facts before touching anything.

I write down three things: the exact error message, the exact input that triggered it, and what changed since the last time it worked. That last question solves more bugs than any tool. A new data file, an updated library, a changed environment variable. Something moved.

To get the exact error instead of a summary, I let the traceback print in full, or log it:

import logging
import traceback

logging.basicConfig(filename="run.log", level=logging.INFO)

try:
    process_orders("orders.csv")
except Exception:
    logging.error(traceback.format_exc())
    raise

The traceback names the file, the line and the type of failure. Reading it slowly, from the bottom up, is the first real step of debugging.

2. Establish a theory of probable cause

CompTIA adds a phrase here that I love: question the obvious. Before you suspect a deep logic error, check the boring things. Is the file where the script expects it? Is it the file you think it is? Is the virtual environment active? Is the API key loaded?

I write my theory as one sentence. "The script fails because the new export uses a different date format." Writing it down keeps me from changing five things at once and losing track of which one mattered.

3. Test the theory to determine the cause

Now prove or disprove the theory with the smallest possible test. I open a Python shell and feed the suspect value directly to the code that failed:

from datetime import datetime

value = "11/08/2026"
datetime.strptime(value, "%Y/%m/%d")

If that raises the same error I saw in the log, the theory is confirmed. If it parses fine, the theory is wrong, and the A+ method says exactly what to do: go back and establish a new theory. No guessing, no random edits. A disproven theory is progress, because it removes one possibility.

4. Establish a plan of action and implement the solution

The A+ wording also mentions considering the impact of the fix. In code, that means asking what else touches this function. If I change how dates are parsed, which other scripts call that parser?

My plan is usually a short list: change the parser to accept both formats, add a test for each format, run the full script on yesterday's file and today's file. Then I make the change on a separate branch so the working version stays untouched until the fix proves itself.

FORMATS = ["%Y/%m/%d", "%m/%d/%Y"]

def parse_date(value):
    for fmt in FORMATS:
        try:
            return datetime.strptime(value.strip(), fmt)
        except ValueError:
            continue
    raise ValueError(f"Unrecognized date: {value!r}")

Notice the function still fails loudly on a format it does not know. Silently skipping bad rows would hide the next problem instead of solving this one.

5. Verify full system functionality and implement preventive measures

This is the step people skip. The error is gone, so they stop. But a fix that breaks something else is not a fix. I run the whole job end to end, check that row counts match what I expect, and compare the output against a known good run.

Then comes prevention. The A+ material means things like updating drivers or adding surge protection. For code, prevention is a test that would have caught this bug:

def test_parse_date_accepts_both_formats():
    assert parse_date("2026/11/08") == parse_date("11/08/2026")

That test now runs every time I change the parser, so this particular bug cannot quietly return.

6. Document findings, actions and outcomes

In a help desk ticket you record the symptom, the cause and the fix. In a code project, the commit message and a short note in the project README do the same job. I write the commit as "Accept month first dates in order exports" and add one line to my notes: what broke, why and how I confirmed the fix.

It feels like overhead the first time. The second time the same kind of problem shows up, that note saves an hour.

Why a hardware method works on code

Years in manufacturing and logistics taught me that troubleshooting is a discipline, not a talent. A production line that stops does not get fixed by the person who guesses fastest. It gets fixed by the person who gathers facts, tests one cause at a time and writes down what they found. The A+ method packages that discipline into six steps anyone can follow.

If you are studying for A+ right now, do not treat the troubleshooting method as a list to memorize for one exam question. Practice it on every bug you hit, in any language. It will outlast most of the other material on the test.

Originally published at tonycantave.com by Tony Sterlin Cantave, a Connecticut software developer.