1

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.

  • 2
    "From my knowledge" – Answers_Seeker Dec 17 '18 at 11:37
  • 6
    Software with no errors hasn't been tested enough. – Simon Dec 17 '18 at 12:51
  • @Simon It is impractical to test general purpose software 100%. To do so would require having access to the combined resources of all the users of the software, and to test against every individual use case that they execute. – Peter M Dec 17 '18 at 13:14
  • @Simon As a professional software QA, I can assure you there's no such thing as bug-free code. Bugs aren't planned; nobody knows they're there until they're found out. No matter how long you test it, all you can really say is "I haven't found any new bugs recently." Even if you do somehow find all the bugs in your program, new ones can surface after some other software gets updated (like the OS, or a third party web source.) When I say there's no such thing as bug-free, understand this isn't about being lazy or negligent in testing. It's just not possible to be 100% sure, ever. – Steve-O Dec 17 '18 at 14:38
  • 2
    I think you guys are missing Simon's point. If you don't find errors, you clearly didn't test. – SaggingRufus Dec 17 '18 at 16:09
3

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.

2

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.

  • Years ago I had an epiphany when I saw a paper on software testing that plotted the discovery/fixing of bugs against time. it was a wonderful asymptotic plot that initially rose steeply and then slowly flattened out as fewer and fewer bugs were discovered. So from such a plot you could say that you are X% sure that bugs had been eliminated - but you could never say 100% sure. – Peter M Dec 17 '18 at 13:19
  • @PeterM You can only know that you found and fixed X% of the bugs that your tester, or your test methods will ever find. – gnasher729 Dec 18 '18 at 0:41
1

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.