You aren't quite specific enough in your question to give a definitive answer. Your reasoning for choosing your subcomponents is important. If you are choosing subcomponents based on random choice, using a most-like/next-most-likely, or system flow model changes the type of strategy you're using.
The way you described the test method was not "divide and conquer." To properly divide and conquer, you would need to find certain components that would indicate major systems being at fault.
Moreover, you're likely optimizing and not troubleshooting. But perhaps both?
I Identify the problem
D Define and represent the problem
E Explore possible strategies or solutions
A Act on a selected strategy or solution
L Look back and evaluate
Trial and Error (this one appears to fit your description):
You pick, more or less, at random to fix a component and then test to see if it's fixed.
You follow a flow-chart or other pre-defined series of steps (this isn't yours)
Apply a general rule to the subsystems to try to identify the issue.
Via knowledge of the system or comparable system, you're able to quickly identify the issue through commonalities between your experiences.
Optimization techniques are far too varied to discuss here. What you're doing looks like a traditional trial-and-error optimization.
System optimization is a hot topic in research right now, especially with computers delivering AI systems that can find patterns that humans cannot. Depending on the system, different principles can be applied to improve or focus optimization.
All in all, I think you're hitting "Trial and Error" for both optimization and troubleshooting.