Category Archives: Debugging

What is troubleshooting? What is it not? (Module 3, ISTE-CS 3e)

For my last week of exploring ISTE Coaching Standard (CS) 3: Digital age learning environments, I focused on indicator 3e – “troubleshoot basic software, hardware, and connectivity problems common in digital learning environments.” I initially started off with different questions, but they led me to these questions:

What frameworks or models are there for troubleshooting? What counts as troubleshooting? And if it doesn’t count as troubleshooting, then what is it?

What is troubleshooting?

Troubleshooting is one of those things that we often talk about without defining. And even more, specific language might be used when defining troubleshooting in a specific context. So based on the definitions or descriptions of troubleshooting from the resources I found, I feel like this general definition summarizes the idea well:

Troubleshooting: “Effective troubleshooting is a multifaceted exercise in diagnosis and deliberation, analysis and action” (Krieger, 2010) for the purpose of attempting to fix a failing or otherwise misbehaving system (Kuphaldt, n.d.).

What is troubleshooting not?

Debugging. This word came up when I asked my friend what general troubleshooting techniques are used in his discipline, computer science. The techniques he told me about didn’t quite match what I was expecting to hear. To me, he was telling me more about debugging techniques rather than troubleshooting, which led us to this forum response on the difference between debugging and troubleshooting:

The difference to a professional software developer is:

“Debugging” usually refers to the act of finding out what is causing a bug in a computer program, done by a person with the ability and authorization to change the computer program to fix the bug once the problem is found and pinned down.

“Troubleshooting” usually refers to the act of finding out how to fix or work around a problem in a computer program one is trying to get to run. Usually it is done by a person who does not have the option to alter the code, but has a program that is supposed to already be debugged. It involves finding conflicts in configuration or the like.

There are definitely overlaps, but they have different main usages. I would suggest that in your context of classroom work, that you use “troubleshooting” most of the time. “Debugging” would apply mostly when attempting to figure out how to alter the lesson plan so the problem does not reoccur on subsequent attempts to teach the same lesson. (Truffula in Debugging vs. troubleshooting, 2014)

The distinction ends up being important due to its implications for a solution. For example, Krieger (2010) says, “It’s common and understandable for users to blame the software or hardware when something frustrating happens that they don’t understand. For a troubleshooter to do the same, however, is an almost certain setup for failure.” I believe Krieger says this because when we believe a problem is caused by a bug, we give up on finding a solution, and the belief that a solution can be found is arguably a prerequisite for persistence in troubleshooting. See Kayne’s (2017) article What is the Difference Between Troubleshooting, Testing, and Debugging? for more elaboration on the differences between these terms.

Problem solving. When you are troubleshooting you are trying to solve problems, but does that mean you’re problem solving? If you are problem solving, does that mean you are troubleshooting? In academia, I don’t think these two words are interchangeable, though, like troubleshooting and debugging, I think they probably have some overlap. The main idea about troubleshooting that seems distinct from problem solving is that troubleshooting happens when a system is failing, misbehaving, or not working as expected; problem solving seems to encompass more than that. Perhaps troubleshooting is a subcategory of problem solving.

The Weyerhaeuser Company has a nice troubleshooting website which outlines the troubleshooting process at their company (it appears that they manufacture things). On their website they distinguish between problem solving and troubleshooting in the following way:

Problem solving is used for longer-term, more complex problems that require more data analysis and a team approach. Working through a problem may take several weeks but will often lead to major improvements in processes, products, or services.

The Weyerhaeuser Troubleshooting Process is designed for “on the floor” situations where time is of the essence. These problems usually take only a few minutes, hours, or shifts to solve. If it takes much longer than that you might consider using a longer-term problem solving process. (source)

Their definition of problem solving doesn’t seem to strictly match the academic use of the term, but I found it helpful nonetheless.

Troubleshooting: The Process

The resources that I found seem to agree on at least three basic steps for troubleshooting:

  1. Know the problem
  2. Narrow down the cause
  3. Verify the solution

But together the resources create a better picture of what troubleshooting entails. This outline strongly resembles *Steve Litt’s Universal Troubleshooting Process (UTP) because his process has the most steps and all the resources I found align with at least one item from the UTP. But this list combines information from Johnson, Flesher, and Chung (1995), Krieger (2010), Davies (2006), Weyerhaeuser Company (2004), Litt (2014), and Kuphaldt (n.d.).

*See the heading titled “The 10 step Universal Troubleshooting Process” for Litt’s elaboration on each numbered step below. I recommend checking it out. There’s a lot he talks about that I don’t mention.

But before getting to the steps of troubleshooting, I think there’s one prerequisite worth listing, which often seems to be assumed.

Prerequisite: In order to troubleshoot, you need at least some content knowledge. Particularly I’m thinking of conceptual understanding of the system and its components (Johnson et al., 1995) and relevant terminology. You don’t need to know all the content, but you need to know enough of something, and obviously, the more the better. It is incredibly difficult to Google something if you don’t know what key terms to use. And beyond that, if you don’t have a conceptual understanding of the system, it can be very hard to use the information you find to answer your own question or to even know to ask a question.

For example, when I was first trying to get my computer to read text to me (see my previous blog post here), I didn’t know the term “screen reader” so I didn’t find that software right away. Then once I found the software, I didn’t have a conceptual understanding of how it worked, so I didn’t know that I should be looking for the “button” command key which will cycle through clickable buttons on a webpage.

1. Prepare: This might require certain tools, software, or setting up your work space. Litt emphasizes having the right attitude and describes that here; I think persistence is one of the things he describes. Krieger emphasizes the importance of always assuming you could be wrong.

I have definitely experienced something like “putting on” a troubleshooting-attitude. I recall a night when my printer wasn’t working. After some halfhearted attempts to get it to work and deliberation over whether or not I really needed to print the thing, there was a distinct moment where I went, “Fine, I am going to commit to attempting to fix this.” After something like 5 hours I finally got it working. I think I cried in celebration.

2. Damage control plan: Litt was the only person I found who mentioned this, but it’s incredibly important! If you’re going to mess with things, make sure you backup whatever content you might affect.

3. Know the problem: You need to be able to clearly state the problem and fully understand the problem. Here are some questions that will help you get a complete picture of the problem:

  • What works?
  • What doesn’t work?
  • How are the working and non-working things related?
  • Have the non-working things worked in the past? Has the problem happened before (prior occurrence)?
  • Have there been recent changes to the system?

I think using the process of Rubber Duck Debugging during this step (and the next) could be beneficial. I say this because the act of trying to email someone about a problem often causes me to refine my answers to these questions.

4. Reproduce the problem: I think being able to reproduce the problem is really a sub-point of knowing the problem because you have to be able to answer the question: Under what conditions does the problem happen? I think sometimes this step might get skipped, particularly if the problem and solution are well documented. But sometimes being able to reproduce the problem is super important.

I can think of a handful of examples off the top of my head when I needed to be able to recreate the problem. Two of my examples involve reaching out to tech support and it’s probably safe to assume that in order to get help from tech support, they will need to be able to recreate the problem themselves (especially if it’s not a known problem).

5. Corrective maintenance: Looking at Litt’s description of this, I think it’d be fair to summarize this as “restart and update” but it includes other things like cleaning terminals. Corrective maintenance includes the things you would typically do for general “system health.”

6. Narrow down the problem: Easier said than done. “Your success or failure lies in what you choose to eliminate, and more importantly, why. It’s a game of Pick Up Sticks where you evaluate, reason, then remove any obstacles that get you closer to resolving the problem without breaking anything else. How you make those choices depends entirely on the questions you ask and how you interpret the answers” (Krieger, 2010). And to pull out some of Litt’s comments from Step 1 Prepare: “Don’t try to fix it, just try to narrow it down. Don’t panic. Don’t get mad. Be patient and don’t skip steps. Practice teamwork. When you get in a bind, just ask yourself ‘how can I narrow it down one more time?'”

7. Solve the problem: Once you think you’ve narrowed down the problem, solve it. Solutions can be broken up into at least two categories: fixes and workarounds. Illig (2010) describes the difference between these two things here. In short, a fix is a solution that will eliminate the problem and a workaround is a solution that will avoid the problem. For example, OwossoBob posted this workaround for the problem of the new Google Sites not (yet?) having a “site comments” feature.

Once you’ve solved your problem, don’t stop here!

8. Verify the solution: You want to make sure the problem is fixed and that the solution didn’t cause another problem. Additionally, Krieger says, “If you don’t know why it works, it isn’t fixed. … If the fix doesn’t work consistently, it most likely doesn’t work at all.”

9. Take pride in your solution! I’m glad Litt included this step because it is certainly a clear stage in the process!

10. Prevent future occurrence: Document your problem and solution and then share the information with your community to help them quickly resolve the problem should they encounter the same issue. This could be a great focus for student blogging on a class blog or website.

Is it Troubleshooting? And does it matter?

Two of my questions at the start of this post were:

What counts as troubleshooting? And if it doesn’t count as troubleshooting, then what is it?

But does it really matter whether your troubleshooting, debugging, problem solving, or doing something else? I think it does because learners will need different kinds of support depending on the activity they are engaged in.

With that in mind, here are three examples of activities I engaged in during my recent “text-to-speech adventure,” which I blogged about here. During that adventure, I did a lot of things, but was any of it troubleshooting? After thinking about troubleshooting more, I decided that a lot of what I did was not troubleshooting.

Not troubleshooting: I’m thinking about everything I went through to learn enough about screen readers so that I could use one to turn on accessibility mode on Ebook Central. And since I didn’t know enough about screen readers in order to have any expectations about how mine should be behaving, I can’t say that at any point my screen reader wasn’t behaving as expected. Therefore, I wasn’t troubleshooting…right? So what was I doing? I think I was engaging in the prerequisite that I listed above: acquiring content knowledge. I was learning the basics of using a specific program, and based on the definitions I’ve read, technically that is not considered troubleshooting. Perhaps this is the kind of activity which would well supported by a “click this button” type of tutorial.

Not sure: I’m having a harder time deciding whether or not I was troubleshooting during a different activity. My favorite text-to-speech reader for Chrome and Safari,, has a Chrome app (here) for their website. It wasn’t immediately clear to me what the app does because the website works without installing it. So I got on two computers at once, one with the app installed and one without, and explored how the features differed based on which computer I was using. Once I realized that the website “remembers” a setting when the app is installed, I started confirming that it remembers other settings too.

Going through this process helped me prevent “a misbehaving website” down the road, and I can see how I might have needed to troubleshoot in the future had I not realized that you need the app for the website to perform as described by the developers. So was I troubleshooting? I’m not sure. I might say I was preemptively troubleshooting because I assumed that not understanding the differences between with-app and without-app would impede my ability to help others troubleshoot in the future. Thinking of myself as part of a community and wanting to support that community was really what encouraged me dig in and find an answer to my question.

Definitely troubleshooting: However, I was definitely troubleshooting when I was trying to add new voices for MS Speak and I couldn’t figure out why it wouldn’t work. The answer to this problem is that there is no known solution to this well documented problem in Windows 7. (It seems to be a bug!) And I suspect that Microsoft’s workaround to this problem is to continue to allow users who utilize assistive technologies to upgrade to Windows 10 for free (see this), rather than fixing the bug on Windows 7.

Troubleshooting and ISTE-CS 3e

Troubleshooting is one of those terms that gets used so much and so loosely that it can seem to become a catchall word for “figuring things out.” In that respect it reminds me of the word “identity.” And for me to be able to engage in CS 3e, it was important for me to go through this process of thinking about what troubleshooting is and what it isn’t. The next step for me would be to think about what it looks like to teach troubleshooting. I know that modeling the troubleshooting process is one way to teach it, but what other ways can we teach and learn it? In the future I think it would also be nice to make an infographic based on the information I found.


Davies, J. (2006). Chapter 16 – Troubleshooting TCP/IP. Retrieved from

Debugging vs. troubleshooting [Online forum comment]. (2014, October 14). Retrieved from WordReference Language Forums website:

Illig, T. (2010). The difference between a workaround and a fix [Blog post]. Retrieved from

Johnson, S. D., Flesher, J. W., Chung, S-P. (1995). Understanding troubleshooting styles to improve training methods. Paper presented at the American Vocational Association Convention, Denver, 1995. Retrieved from

Krieger, S. (2010). Troubleshooting 201: Ask the right questions. Retrieved from

Kuphaldt, T. R. (n.d.). General troubleshooting tips: Troubleshooting -Theory and practice. In Lessons in Electric Circuits: Vol. V (ch. 8): Reference. Retrieved from

Kayne, R. (2017). What is the difference between troubleshooting, testing, and debugging? Retrieved from

Litt, S. (2014). The Universal Troubleshooting Process (UTP). Retrieved from

Rubber duck debugging. (n.d.). In Wikipedia. Retrieved August 19, 2017, from

Weyerhaeuser Company. (2004). Troubleshooting [website]. Retrieved from