In a scenario where it's near impossible / too difficult for me to guarantee that there will be no errors, how do I answer that question without making my clients/supervisors anxious?
closed as primarily opinion-based by gnat, user34587, Mister Positive♦, Snow♦ Dec 18 '18 at 7:25
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
You find errors by testing. (Errors may be bugs, in software. Defects, or other labels, as appropriate, in other settings). You test by measuring fitness against requirements. You answer the question "are there errors?" based on results of testing against known requirements: It's equivalent to saying, "Does the work product do what we asked of it?"
I point that out, because it's a flat question at first (are there unresolved failed tests) but has an implication (did we define the requirements well enough to know what the end product is supposed to be).
The conclusion is, in order to answer the question, you need to know if you and the person(s) asking it agree on the requirements, first of all, and then you need to understand if your testing was thorough enough to inspire confidence.
Personally, when answering questions like this, I tie the answer back to the requirements where possible. Some equivalent "well, when I press this button, this is what happens, which matches what you asked for." This lets you demonstrate that you know the functional purpose for your work, and by repeating it out loud, it gives the other party a chance to reflect on how your work was defined.
You can never guarantee that there will be no errors. Based on the level of testing that has been done, you should have a general idea.
If it was tested thoroughly, you can tell them something like:
While it is impossible to say there are no errors, I am confident in the testing that was done. At this point in time, I have no reason to believe there are any more errors.
On the flip side, if there was not enough testing done, you can't really feel confident at all and you should be honest about that and tell them.
From my experience, you could say something like
We have tested the software, fixed the bugs we found and we think we have a very stable program.
Anyway, it's important to let know that there always be bug chances, and that is not possible to reproduce EVERY production situation, BUT immediately after that to ensure that you will be available to fix them if the occur, and that those bugs should not make the software unusable to them.
So, you can add something like
There's no way we can cover every possible situation that can happen in production, but we are sure that any bug won't stop you from working with the software. Also, if you have any problem you can report it, and we will try to find a solution and fix it as soon as possible. You can count on us for that.
So, with something like this, you make them feel that even if a bug appear they have someone to help them. Even if later you can't help them, the important thing here is to give them that feeling.