16

I'm a web application developer for an internal system. A user reports that there's a bug.

The bug was that some words could not be displayed. The report contains a screen capture which clearly show the bug. But the report is almost a month old and the bug can no longer be reproduced in our production environment.

How should I reply to the client and the user?

closed as primarily opinion-based by yannis Dec 2 '15 at 7:47

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.

  • 5
  • 1
    Figure out how to make it repeatable. – Wyatt Barnett Dec 1 '15 at 14:22
  • 2
    How much time can you afford this investigation ? How critical was the bug and it's negative effects ? If the answers are Very little and negligible then I'd say marking it fixed with a note of the circumstances under which it's not really fixed and wait for it to come back is a perfectly acceptable use of your company's resources. – Newtopian Dec 1 '15 at 14:44
  • 2
    This just calls for a pretty standard boilerplate response: "Dear [user], The issue with X that you reported on the Yth seems to have been resolved with the latest release of Z. Please mark the issue as resolved if that is indeed the case. If not please send this back to me with details on how you encountered it." – Lilienthal Dec 1 '15 at 14:50
  • 1
    @Lilienthal Just because a bug cannot be reproduced does not mean it has been resolved. You don't even know there has even been a new release in the last month. – paparazzo Dec 1 '15 at 15:54
32

Revert your dev environment to the version that the bug was noticed in and verify that the bug is there.

If it is there then you can investigate the bug and make sure that the current version doesn't have it. Then close the bug report with the comment that an unrelated change fixed it. Add a regression test if needed.

If you can't reproduce the bug in that version then the strategies laid out in many other questions here will be of use (Thanks Thomas for the initial list):

  • 2
    In my experience, most teams just check the "cannot reproduce" option in the ticketing system and close it. Testing the "then" and "now" code to ensure the issue was there and no longer is seems like a better solution. But it is also more time consuming than saying "cannot reproduce" and closing it, so it may not be an option for every bug. – Paul J Abernathy Dec 1 '15 at 15:35
  • 5
    Depends on how serious the bug is. If it's just a layout goof then indeed a couldn't repro stamp and be done, but if it could be more sinister then a few hours to end up with a regression test can be worth it. – ratchet freak Dec 1 '15 at 15:40
  • 2
    @ratchetfreak Alternatively, it depends on how serious this particular customer is. If they're singlehandedly funding your paychecks, maybe its worth humoring them ;-) – Cort Ammon Dec 1 '15 at 16:47
  • 7
    Problems that go away by themselves come back by themselves. – Pete Becker Dec 1 '15 at 17:10
  • 1
    It's all a matter of workload. If you have one bug that was reproducible a month ago and isn't anymore, and another bug that is reproducible now, then you fix the one that is reproducible now first. If you ever get to a state where you are totally bored, then you may investigate. And when the problem comes back by itself, then of course it is a reproducible bug and you start fixing it :-) – gnasher729 Dec 2 '15 at 9:08
2

I am going to assume that you have genuinely done everything you could to reproduce the bug but can't.

In a case like this it is often best to add some code around the area of the application that failed to log the work being done, so that hopefully you will have more data to work form if it happens again. Think through what information you need to have that you currently don't have available. For instance, maybe it only occurs when a particular set of input parameters are sent and so you record those every time the process runs. Check with your boss however before you do this, depending on the importance of the bug and the frequency of which it occurred, he may not want to spend the time to do this.

Then you go the the person who reported the bug (you can do this in the bug tracking application if you have one, you don't have to go in person) and say that you were unable to reproduce the bug but have added some additional logging to get more detail of what the process is doing in case the bug reoccurs. Then close the bug.

If you can't do additional logging. simply report that the bug was not reproducible and that if they run into it again, this is the information you will need to reproduce it and tell them what you need. We often ask them to tell us exactly what input parameters they were putting in when they got the error. Just having a screen shot of the error helps but knowing exactly what steps they were taking and what information they tried to use at the time the error occurred is more helpful. So basically you are putting the onus back on them to give you more information when they report the error if it occurs again.

In your bug tracker, be sure to explain what steps you tried, so that if the bug occurs again, the person handling it will have some background in what was done before.

1

Non-reproducible bags are the worst! It may have been fixed in the meantime, or it may still be there but is sporadic or the steps-to-reproduce is insufficiently specified. You have to make a judgement call on how high-risk the bug is, and how much you will expand on investigating it. Are you making an online recipe-manager, or steering control software for nuclear missiles?

If it is a low-impact bug, and you know changes have been made which could have resulted in the bug being unwittingly fixed, it may be acceptable to close the bug with the note that it is not reproducible and you assume it have been fixed.

If you are more concerned, you could make some theories about what caused the bug in the first place, and look through change log and source history to see if you can spot where it was fixes.

For a more serious bug, you will have to roll back the source to the point of last release, and then try to reproduce. If you reproduce successfully, you can write tests to ensure it is fixed in later commits.

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