Divide and conquer terminology for improving / troubleshooting hardware

What you're describing is procedurally (or conceptually) similar to a binary search.

From an article on Brilliant:

Binary search works by comparing the target value to the middle element of the array. If the target value is greater than the middle element, the left half of the list is eliminated from the search space, and the search continues in the right half. If the target value is less than the middle value, the right half is eliminated from the search space, and the search continues in the left half. This process is repeated until the middle element is equal to the target value, or if the algorithm returns that the element is not in the list at all.

In a standard binary search, using an array with alphanumeric elements, the elements are first sorted. But in terms of troubleshooting hardware, the idea of "sorting an element" is somewhat meaningless and unnecessary. Also, a binary search works on exactly half of an array during each iteration—something which will likely not be the case with hardware troubleshooting.

The general approach is the same, however. You eliminate variables from the overall field of possibilities, then continue to apply the same process to the remaining variables until the culprit is identified.

The term "divide and conquer" is applicable, because you are dividing hardware components into groups—and then eliminating all suspect components in one group or the other en masse.

What you're doing is not actually a binary search, but it carries the same general meaning.

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?

Troubleshooting Types

IDEAL Method 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.

Algorithm-Based: You follow a flow-chart or other pre-defined series of steps (this isn't yours)

Heuristics: Apply a general rule to the subsystems to try to identify the issue.

Insight: Via knowledge of the system or comparable system, you're able to quickly identify the issue through commonalities between your experiences.

Optimization Techniques 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.