The Trouble with Troubleshooting Training

One of the best courses I've ever been on. They also have a course on Analytical Troubleshooting.

Its not cheap, but its worth it. I doubt they would let you teach it yourself, but you can bring one of their trainers in to your facility - one of my former employers did that - with great success.

James

Good ones have it down to an art form. They don't guess.
Start at one end test until it goes faulty or goes correct. I worked with a lot of good ones, they all do it, so they must have a reference somewhere. I use their methodology all the time now. Even to the point of testing things I 'know' must be right, just in case they are not.
Designing modular software so you get good test points would be a fine thing to teach as well. I do that too, designing not teaching.

Good troubleshooting /fault finding is actually an attitude. Naivety, basically, no assumptions.
Sharpen your pencil, step back and ask your self now what have we got here then?

Most good trouble shooting anecdotes come down to assumed fault was here, spent hours looking in completely the wrong place.

Not sure about anyone else here, but I think that the most important key in troubleshooting is the experience that comes with previous cases. Sure, learning things from books is quite beneficial, but when it comes to the crunch time - if you've done it before and have had experience doing it, it'll be alot more easier to remember.

What do you think?

Good troubleshooting requires system knowledge, a method, and documentation.

System knowledge allows the technician to isolate defective subsystem--there's no point troubleshooting the display system when the PC power supply is bad.

The method is a logical way of applying the system knowledge to isolate the fault. The best troubleshooting method I know is what the USAF used to call the "half-split" method. It's essentially a binary progression.
--Check the signal at a point in the middle of the system
--Is it good or bad? If it's bad, choose a point midway between there & the front of the system; if it's good, pick a point midway between there & the system output.
--Again, is the signal good or bad?
--Continue thus, always splitting the remaining section and moving toward the bad area until you find the faulty part.
On a complex system, this method saves troubleshooting time by allowing you to eliminate half of the remaining system with each test. What could have taken an hour in a sequential search has taken 10 minutes or less.

Good documentation is also required. While a fault chart or troubleshooting tree are handy, the best documentation will also include an explanation of system operation and the interaction of the subassemblies. Good documentation and overall experience can substitute for equipment knowledge, but only just. Although my troubleshooting skills were developed over thirty years of electronics & IT support, without documentation I wouldn't have the first idea how to find a problem in an unfamiliar system except to trace the signal through point-by-point.

I can't recommend a source for this training, but a Google search on "teaching troubleshooting training" yielded 975,000 hits (including this discussion!).

I found this link:

http://www.troubleshooters.com/ustep6.htm

If you design you trouble shooting "tests" to elimate half the system you will find the problem quicker. I am leaning toward focusing on this method.

When being taught or teaching troubleshooting, I have found only one method that really works. Physical, practical test. You can explain the theory of troubleshooting until you are blue in the face, but sit someone down at a computer that has a problem, and they will have to learn troubleshooting techniques to solve the problem.
I think this encourages the persons unique abilities to emerge from them too.

This web site covers it for auto/truck electrical electronics troubleshooting training: www.veejer.com
You don't have to re-invent the wheel.