As a thought experiment how many questions does your software ask and answer?
As an approximation search for words like:
interface. Sum up their counts. That is a low ball-park figure.
Now when this software executes it plays a choose your own adventure story walking through each question and bouncing to this page or to that page.
A simple program that does 1 thing like copy a file, still has many paths it can take. A Large file vs a small file, from/to a fast/slow drive, across file systems, different filesystem paths.
A complex program has infinite paths, like just about any GUI program. Every user event occurs at different times, in different contexts, producing different layerings of response.
As a very rough thumbnail. Presume your system has roughly
operational life time in seconds * factorial(the number of decisions) unique paths. There is a bug in one, or more of those paths. Find it.
If you aren’t quaking about the factorial in that approximation, you really should be. Its get large really fast. The more complicated the program, the even quicker it grows. This is why a large program is guaranteed to have bugs, and why so much effort is put into making programs simpler and smaller.
This is why it is so essential to describe as much information about the bug as possible.
The basics like:
- What was wrong.
- What it should have been.
- Which screen, report, extract, email.
- When it has occurred
- Who it has occurred to
- Which version
… are important. They help close down a lot of possibilities for where the bug could be lurking.
But in a complex software eco-system its just not enough.
Ideally there would be a testing tool that support have access to that allows them to recreate the situation inside an automated test. Even if the test is slow, and does way more than it really needs to. All of that can be worked on. The important part is that it exactly reproduces the issue.
Short of having that the next best tool is a manual test. Do this, then that, click this, and voila. This is also know as steps to reproduce. The more accurate these steps are, the easier it is going to be to find the bug. If these steps are inaccurate/not there then it is pure luck if the developer spots the bug.
Also to the description of a mechanic and a driver, its the wrong analogy. Support are the mechanics. The driver of the vehicle is the client. Developers are the designers working on the car production factory.
Support do need to know what components make up the vehicle, and be able to describe accurately the effects of real world usage on those components. IE. Did you know the computer board A, burns out really quickly for high way driving users? In software speak Did you know that the last day of the month batch process X takes 3 times longer to run, but the input is the same size as every other day that week?
If support just communicates back to the developers. Hey your product is broken. you can expect them to be ignored, because of course its broken. It arrived broken, or it has been misused to the point of breaking. That’s supports problem.
What is not supports problem is a structural defect with the product itself. Not with how it was delivered, or how it was used. They would communicate this exactly like a mechanic would to the car manufacturing company. In circumstance X, Y, Z. Following these normal system usage patterns. Some P% of the time Q happens. Doing F reduces P% or increases P%. If you do M the Q changes to Q2.