Internet forums are a great resource for troubleshooting issues with just about anything. There is a truly staggering wealth of built-up knowledge on this site and others, and even better, all of this is freely available to those who search for it. Unfortunately, all too often issues are dragged out for much longer than necessary creating frustration for both the original poster with the issue and everyone else trying to help them.
I saw this exact scenario unfold countless times in my job as a product support engineer for semiconductor equipment. These are large, sensitive, and highly intricate machines with countless ways for something to go wrong. In most cases, we were expected to resolve issues with equipment on the other side of the world, and the only insight we had into the tool status was relayed by inexperienced engineers who spoke little to no English. It was a recipe for disaster, and our company developed an extremely structured template for helping both sides determine and resolve the problem quickly. I've adopted these techniques for solving issues on my own car and others on this site, and it's remarkable how adaptable they are for pretty much anything.
This is a condensed version of those techniques, paraphrased and interpreted by me. I'm sure this will be very similar to other guides available online, but none were knowingly borrowed for this writeup. Note also that a technical background is not required for successful troubleshooting, although it can definitely help speed up certain aspects of it. My degree is in mechanical engineering, but there were other successful engineers in my group with little prior engineering experience. Experience greases the wheels of progress, so as you test yourself more and more, troubleshooting will become much easier with time.
TL;DR: You do not need to be a certified mechanic to troubleshoot issues with your car.
The program is based around several critical steps:
1. Define the Problem!
This sounds obvious, but it's surprising how often this is skipped, or at least very poorly developed. Clearly define in objective terms what the issue is. For example, instead of saying, "my car is feeling sluggish lately" which is not definable in numerical terms, state "In third gear, my car is taking 4 seconds to accelerate 2000-4000 rpms when it took 2 seconds last week." This is a measurable statement that can be used for comparison later to tell if the problem is resolved (see step 2). It also sets you up with a potential troubleshooting path later, but let's not get ahead of ourselves. Stating the problem clearly and concisely will help focus you and others later on the direct issue at hand, and prevent sidetracking and rabbit trails later in the troubleshooting process.
TL;DR: Clearly define the problem in specific, measurable terms.
2. Define the Success Criteria
Again, this seems obvious, but is easily missed. Similar to the problem statement, the success criteria should be clear, measurable, and concise. You cannot cheat and define this as "problem fixed". Borrowing the example from above, one might say "In third gear, the car accelerates from 2000-4000 in two seconds." Note that this statement borrows a lot of information from the problem statement, making the Problem Statement more critical between the two, but sometimes the success criteria won't be so obvious.
For example, say you have a intermittent CEL every other week or so. It doesn't occur all the time, so just saying "CEL turned off" wouldn't necessarily mean the problem is fixed. In this case, it would be beneficial to add a monitoring period: "CEL does not occur for one month". Since you see the issue more than once a month, if you don't see the issue in that time, you can be confident the issue is resolved.
TL;DR: Clearly define the goal in specific, measurable terms.
3. What are the facts?
Now that you know what the problem is and what the end goal is, it's time to start connecting the dots. Problems rarely occur out of nowhere, so gathering a history of events will often give a clear set of clues into what went wrong. This is also where I'll focus more specifically on troubleshooting a car, but these questions can be applied in general to a lot of devices. In the context of this site, "The Three M's" are a good place to start: Mileage, Maintenance, and Modifications. First, how old is the car? How many miles? When was the last service? Any outstanding maintenance items? What modifications have been performed? Anything unusual happen before the issue? It is important to understand what has changed since the issue appeared.
At the bare minimum:
- What is the car's age and mileage?
- When was the last service?
- What was done at the service?
- What modifications have been made?
TL;DR: Collect the facts and discover what has changed.
4. Form a plan of attack
Now that you know know the problem, the end goal, and have the facts in front of you, it's time to form an action plan. With enough preparation, this should be an straightforward task. Following the summary statement above, determine how changes occurring before the problem statement might have affected it. For example, if your problem is: "I hear a belt squealing noise", and one of your facts is "I replaced the alternator yesterday", then look at what those statements have in common: "I had to loosen the accessory belt for the alternator, so maybe I didn't properly re-tension the belt?" This is a basic example, but illustrates how an action plan will fall into place when looking for changes. Again, cause and effect is critical here, and experience/training will help connect the dots.
For more difficult situations, there are a lot of templates online like "fish bone diagrams", "mind maps", and other tools to help you make these same connection. These are usually tailored for group collaboration, but can be used by an individual as well. These are also helpful to save for future reference, and can form your own troubleshooting library.
Online web app for creating mind maps: http://creately.com/diagram-type/tem...nd-map-example
Online web app for creating fishbone diagrams: http://creately.com/diagram-type/tem...shbone-diagram
TL;DR: Connect the sequence of changes to the problem statement, forming an action plan.
With your plan in hand, it's time to execute! Perform each action item and record your findings. Analyze the results of each test and compare them against the success criteria. Depending on the issue, this can be an iterative process combined with Step 4, where the results of an action item are used to form new plans.
TL;DR: Execute and iteratively develop the action plan.
6. Still stuck? Ask for help.
At this point, you've got a clear understanding of the problem, the goal, the background and facts, and have a complete list of troubleshooting actions completed. Still stuck? That's ok! You've got everything you need to bring in outside help. Organize each of the above key steps in a post, and you'll have plenty of information for others to help brainstorm. When organizing your troubleshooting data, bear in mind that proper punctuation and grammar really do matter. Like it or not, with no face to face interaction, your intelligence is measured by your writing. Showing you're willing to put forth effort and contribute to a well-written thread goes a long way toward motivating others to help you. Remember that nobody on this site is paid to help you solve your problem, so the more helpful you are, the more help you'll get! Donkey has created an excellent sticky with more information RIGHT HERE! Here are some key points:
- No "walls of text"
- Proper grammar and punctuation matter.
- Don't forget that nobody is paid to help you!
TL;DR: Summarize all your findings into a clean, easy to read format for others to contribute.
Congratulations! You've solved the issue yourself and have hopefully learned something along the way. Take a second at this point (while sipping a frosty cold one) to review what you learned, what methods worked well, and what actions didn't work. This will hone your skills for the future, and help streamline your troubleshooting efforts later.
TL;DR: After the problem is resolved, reflect on what you learned for next time.
I'll continue to flesh out more of this, but that's all for now. If you have any questions or comments on all this, fire away!