There is no substitute for gaining hands-on experience at troubleshooting failing circuits in the lab. The more strange things you see and eventually solve, the better you get at it.
It helps to know the system inside and out, and have a thorough checklist that starts with the most basic things like assembly errors and verifying correct supply voltages at all the right places.
Once you work your way through the list of most probable causes and still haven't solved the mystery, start working through the list of improbable causes. Think outside the box, and start visualizing all those invisble resistors, capacitors and inductors that aren't on the schematic. Remind yourself that although what you're observing might seem impossible -- that the circuit should never behave that way -- the fact is, circuits don't lie, and there are no displeased "electron gods." Physics governs, and when you finally find the root cause of the problem, it will seem so obvious that you will wonder why you didn't see it sooner.
Troubleshooting is absolutely one of the most important skills to be a good engineer, in my opinion, to be a good manager. Question is what knowledge we all need to be a good troubleshooter. To me, the thorough understanding of system is very important. W/O understanding, I, at least, will have hard time to start. However, documentation may not be always available. Even it does, it may not cover the whole 9 yards that you will need to get the job done. So, what else? Experience. I remember the first undergraduate project years back - a class A amplifer. The first symptom is it doesn't even ampilifer any signal. After sometimes, I just found out the transistor was blown to begin with. Understanding how transistor works definitely come handy. The 2nd symptom after signal was coming out of the output - noise and signal clipping. Apparently, power supply didn't give a clean voltage and amplification was larger than calculated. With twist of resistor and building of feedback loop, the issue was relief. This is a simple project and yet, I have learned a great deal as a freshman in engineering school. Later on, with years of on the job training, when I became manager, I was able to build a checklist to troubleshoot and guide my subordinates to resolve most issues in a timely manner.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...