Diagnosing faults
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!
- Avoid "blind alleys"
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.
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.
Cases
Kettle
Mysterious kettle owned by the venue - we did not know the circumstances of the fault.
- 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
The laptop owner (a very expert user) told the Restarter the harddrive needed "debugging" - led to blind-alley
- Ran a harddrive diagnostic tool (ok)
- 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