Diagnosing faults: Difference between revisions

(Created page with "== Our troubleshooting tips == This is one of the hardest things to "teach" - it is mostly learned through experience. This is like a kungfu dojo - the more you practice, the ...")
 
mNo edit summary
 
(12 intermediate revisions by 4 users not shown)
Line 1: Line 1:
== Our troubleshooting tips ==
<languages/>
This is one of the hardest things to "teach" - it is mostly learned through experience. This is like a kungfu dojo - the more you practice, the more you have confidence in the tools/process. But here are some tips  
<translate>
<!--T:1-->
Diagnosing the problem can often be the hardest part of a fix, in which case a methodical approach may save you a lot of frustration and wasted time. Here are some tips for how to proceed.


===What to avoid===
== Our troubleshooting tips == <!--T:2-->
*Don't leap to easy conclusions!
*Avoid "blind alleys"


===Gathering the evidence===
<!--T:3-->
This is one of the hardest things to "teach" - it is mostly learned through experience. This is like a kungfu dojo - the more you practice, the more you have confidence in the tools/process. But here are some tips.
 
===What to avoid=== <!--T:4-->
 
<!--T:5-->
*Don't leap to easy conclusions! Have you taken into account all that you know about the problem?
*Avoid "blind alleys". If your current theory is getting you nowhere, be prepared to admit that it might be wrong!
 
===Gathering the evidence=== <!--T:6-->
 
<!--T:7-->
We have a number of ways to gather evidence about the fault, often we have to mix and match.
We have a number of ways to gather evidence about the fault, often we have to mix and match.
* Description of the fault from the owner/user (sometimes this can be misleading and/or 'wrong')
* Description of the fault from the owner/user (sometimes this can be misleading and/or 'wrong')
Line 14: Line 25:
* Functional testing (when safe and possible)
* Functional testing (when safe and possible)


===Following a logical process===
===Following a logical process=== <!--T:8-->
 
<!--T:9-->
* It really helps to know how something works! (This may sound obvious, but it's worth reading about how the e-thing works.)
* It really helps to know how something works! (This may sound obvious, but it's worth reading about how the e-thing works.)
* Start investigating in a logical, sequential way where you move from parts you know are working towards parts you know are not working.
* Start investigating in a logical, sequential way where you move from parts you know are working towards parts you know are not working.


===Root cause or causal factor?===
===Getting help=== <!--T:10-->
 
<!--T:11-->
* Remember, search engines are your best friend, but to get a good answer, you need to ask a good question.
* If you're running out of ideas, explain the problem to someone else. If there's a flaw in your logic or another way to tackle the problem you may well see it even before you finish the explanation, and even if your audience didn't understand a word you said or only asked silly questions!
* Creep up on a problem from every possible angle. Sooner or later, with luck, you'll catch it out.
 
===Root cause or causal factor?=== <!--T:12-->
 
<!--T:13-->
* Fixing the "root cause" will permanently clear the fault.
* Fixing the "root cause" will permanently clear the fault.
* Fixing only a "causal factor" (such as replacing a blown fuse) may make something work again, by the "root cause" may still be present and the fault will reoccur.
* Fixing only a "causal factor" (such as replacing a blown fuse) may make something work again, by the "root cause" may still be present and the fault will reoccur.


==Cases==
==And Now ...== <!--T:14-->


===Kettle===
<!--T:15-->
Mysterious kettle owned by the venue - we did not know the circumstances of the fault.
Don't forget to visit our [[Case Studies|Case Studies]] page to see some of these principles in operation.
* Check the fuse (ok)
* Visual inspection (ok)
* Tested for continuity from the mains plug to the base (ok)
* Tested base for resistance and continuity (ok)
* By logical process, '''the only thing left''' was the physical contact between the kettle jug and the base - turned out it was not making a solid contact and needed to be remade


===Laptop===
<!--T:16-->
The laptop owner (a very expert user) told the Restarter the harddrive needed "debugging" - led to blind-alley
[[Category:Fixing]]
* Ran a harddrive diagnostic tool (ok)
</translate>
* Mounted the drive (ok)
* Inspected system log (ok)
* Booted on Linux and noticed there was rubbish coming up on screen at boot - suspected a keyboard or touchpad fault - isolated the keyboard fault

Latest revision as of 11:09, 26 July 2021

Other languages:

Diagnosing the problem can often be the hardest part of a fix, in which case a methodical approach may save you a lot of frustration and wasted time. Here are some tips for how to proceed.

Our troubleshooting tips

This is one of the hardest things to "teach" - it is mostly learned through experience. This is like a kungfu dojo - the more you practice, the more you have confidence in the tools/process. But here are some tips.

What to avoid

  • Don't leap to easy conclusions! Have you taken into account all that you know about the problem?
  • Avoid "blind alleys". If your current theory is getting you nowhere, be prepared to admit that it might be wrong!

Gathering the evidence

We have a number of ways to gather evidence about the fault, often we have to mix and match.

  • Description of the fault from the owner/user (sometimes this can be misleading and/or 'wrong')
  • Nature of the onset
  • Visual evidence
  • Passive testing (e.g. with a meter - resistance can be useful)
  • Functional testing (when safe and possible)

Following a logical process

  • It really helps to know how something works! (This may sound obvious, but it's worth reading about how the e-thing works.)
  • Start investigating in a logical, sequential way where you move from parts you know are working towards parts you know are not working.

Getting help

  • Remember, search engines are your best friend, but to get a good answer, you need to ask a good question.
  • If you're running out of ideas, explain the problem to someone else. If there's a flaw in your logic or another way to tackle the problem you may well see it even before you finish the explanation, and even if your audience didn't understand a word you said or only asked silly questions!
  • Creep up on a problem from every possible angle. Sooner or later, with luck, you'll catch it out.

Root cause or causal factor?

  • Fixing the "root cause" will permanently clear the fault.
  • Fixing only a "causal factor" (such as replacing a blown fuse) may make something work again, by the "root cause" may still be present and the fault will reoccur.

And Now ...

Don't forget to visit our Case Studies page to see some of these principles in operation.