1

A customer has reported a bug that neither them nor us have been able to reproduce. This is the only report of this bug happening so far.

We've spent a lot of time trying to replicate the issue (followed the customers' exact path, with their same browser, and even set the server and local machine clock to replicate the time the bug occurred).

Given that we can't fix a bug we can't get to happen again - how should we proceed? Should we log the bug and wait to see if it happens again or is it critical that we not move on until it is reproduced? What point is it acceptable to "cut our losses" with finding the problem? What should be communicated to the customer?

Thank you all for your advise!

3
  • 2
    This question really has nothing to do with software engineering, it's a customer service issue. The decision on how to respond and what to do next is a business one, so you need take this up with whoever at your organisation is responsible for decisions related to customer service or product management. Jun 24 '20 at 17:21
  • 2
    @BenCottrell: if you don't insist to read the question literally, but read it as "How to deal with the situation when a bug can't be reproduced", it becomes a software engineering issue (and how to include a customer into the situation can indeed be part of a solution). However, I guess this is a duplicate, I may have answered something similar some years ago.
    – Doc Brown
    Jun 24 '20 at 19:07
  • 2
    Ok, not a 100% dupe, but very similar question: Dealing with non-reproducible bugs - just replace "project manager" by "customer" in the question and transfer my answer to your situation.
    – Doc Brown
    Jun 24 '20 at 19:12
10

Customers generally at least begrudgingly understand if you can't reproduce a bug, especially if you have worked with them and made very visible attempts. What it usually takes to close such bugs is some sort of mitigation.

If it happens again, have you put something in place that will prevent data loss, give you more info to be able to track it down, etc. Have you fixed any compiler or linter warnings in that area of the code? Have you beefed up your test coverage, ideally even writing a specific test for that specific failure? Have you eliminated usual suspects like concurrency issues and null pointers? Have you added gratuitous checks for "impossible" states?

Put that in the bug report and give them confidence that you have reduced the impact even if you haven't eliminated it.

1
  • 1
    Just to further extend this answer, having worked on a helpdesk, focus on the fact that even a closed ticket can be referenced in the future and will still contain all relevant information. "We're closing your ticket" (or as a question) gets considerably more negative reactions than "We're closing the ticket for now but I'll give you the ticket number so you can refer back to it should this happen again in the future".
    – Flater
    Jun 25 '20 at 11:57
2

Respond politely and honestly.

Document your attempts to reproduce the bug. Add logging capabilities if possible. Clean up the code around the bug to the best of your ability. If this bug ever comes up again, you want to build up a backlog of evidence on how to fix it.

Sometimes you'll fix the bug while working on other things and never notice. Sometimes a small change turns a rare bug into a common bug. You want to be ready if that happens.

With regards to the customer, transparency and honesty is the best way, in my experience. Do what you can to help them be confident that it should not happen again; tell them you have tried to reproduce it and have not managed to; have them stress test it; show them your documentation on the reproduction effort if you must.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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