Dividing the problem space is the goal of debugging. Remove things that cannot be true so you are left with only what is possible.
To that end, trial and error is not trying something, finding it doesn't work and trying that something else while you ignore the first test. It is not a series of unrelated failed trials. It's a trial whose errors determine the following trial.
The same thing can be applied to many areas.
For information gathering - run a test and see what happens. Then learn from it. Yes, actually change your mind based on what you saw. This is something that seems impossible to many people, to take notice of the reality of their own tests.
This is why trial and error is so good a reducing the problem space.
The best trial is one that reduces the problem space as much as possible. A typical ball ache of a problem is "why doesn't my email get through from my server". Well, the first thing to test is do any emails get off the server because that divides the problem between server-thingies and internet-thingies.
Choose your trials well. Treat them as expensive.
Imagine each trial costs you $1000 of your own money. You have to walk to the bank to get the cash because the people running the test are builders and prefer to be paid in cash. On the walk back form the bank you decide which of the tests should be run.How do you decide which test to run?
You want to get the most from your $1000. You don't want to find out something you already knew or something you can't base a decision on. You always want to make the problem space shrink so you're looking for the biggest reduction you can make for your $1000.
So what do you spend your $1000 on?
Suppose you have 5 tests you can run? Which one do you buy first?
Differential diagnosis[link] is the tool here. Imagine you already have the results. What do they tell you? If you can't write out the results of the test, chances are the test isn't going to help you right now and it's just a debugging habit kicking in.
A good trial gives lots of information. Lots.
Again: what is the next trail going to tell you? Don't start the trial before you know the outcomes you've looking for, otherwise you're just poking at a thing hoping something oozes out.
Read the outputs
If you've created the trials well, you'll be expecting the right outputsIf misused, trial and error is essentially brute-force, but I would suggest that each error should feedback into the following trial.
Avoid bogosort
Remember that trial and error is trial not just repeated errors. The reverse - what you are trying to avoid - is nicely described by bogosort: throw up in the air, pick up. If in order, ok. If not in order, repeat.
