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?
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):
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.
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.
