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?

Ben Cheng
  • 349
  • 1
  • 10
  • 5
    We have several related questions here on Programmers: [Turn away a bug if no reproducible test case exists?](http://programmers.stackexchange.com/q/61558/4) [How do I isolate difficult to reproduce bugs?](http://programmers.stackexchange.com/q/102819/4) [How to most effectively debug code?](http://programmers.stackexchange.com/q/10735/4) [Un-Explainable Bugs?](http://programmers.stackexchange.com/q/74362/4) [What to do with bugs that do not repro?](http://programmers.stackexchange.com/q/1376/4) – Thomas Owens Dec 01 '15 at 14:10
  • 1
    Figure out how to make it repeatable. – Wyatt Barnett Dec 01 '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 01 '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 01 '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 01 '15 at 15:54
  • https://en.wikipedia.org/wiki/Heisenbug – Peter Dec 01 '15 at 16:08
  • Did you ask the user if they are still getting the bug? Was is it just a one time thing almost a month ago? – paparazzo Dec 01 '15 at 16:14
  • @Frisbee If I had to investigate every phantom bug ever reported by a *user* my brain would have liquified years ago. Unless you're dealing with a reliable user and a critical bug in a critical application you generally shouldn't waste time on an unconfirmed bug. The critical phrase in the question is "no longer" reproducible. – Lilienthal Dec 01 '15 at 16:56
  • Frankly, while I appreciate that a Programmers mod wanted this question migrated here, I'd recommend closing it as a duplicate/unclear until the OP actually signs on here and can flesh out the question. – Lilienthal Dec 01 '15 at 16:58
  • @Lilienthal What does my comment this have to do with investigate? Yes the key phrase is "no longer" reproducible so why not use that term rather than resolved and again you have no basis to assume a new release came out in the last month. – paparazzo Dec 01 '15 at 17:05
  • 1
    @Frisbee One, the language was "seems to have been resolved," which is honest. Two, it doesn't invite the user to keep yelling at the dev to "try harder" to reproduce it. The goal here is to get them to shut up until there is larger evidence of a problem, because users don't understand their having seen a bug a while ago once is not really that important (unless the code keeping a plane in the air or something). Three, if I may, I believe Lilienthal was assuming the OP can generalize and not say there was a release last month if there wasn't. – djechlin Dec 01 '15 at 18:00
  • @Frisbee As djechlin said, that's just a standard phrase to give to a user. My assumption that there was a release is that the bug was apparently reproducible a month ago but isn't any longer. While there are a variety of reasons for that (like changes to the data involved), a release of a new version is one of the more likely. As for investigating, what exactly are you suggesting that the OP do then? Either the bug is indeed no longer there, in which case you mark it resolved or it's still there and someone has to investigate the cause, *after* the user has reported that it's still there. – Lilienthal Dec 01 '15 at 18:11
  • @Lilienthal And you cannot assume it was reproduced a month ago based on the language in the question. He said the report is a month old. I am suggesting you use honest language with the user "cannot reproduce". If you say resolved and the user still has the bug or it comes back up you look bad. I would just use honest wording with the user - cannot reproduce. – paparazzo Dec 01 '15 at 18:22
  • @djechlin Maybe your goal is to get them shut up but I like to go with open honest communications. – paparazzo Dec 01 '15 at 18:28
  • Using git? Use bisect reverse in order to find the commit that fixed the issue; http://stackoverflow.com/q/15407075/520162 – eckes Dec 01 '15 at 18:31
  • 1
    @Frisbee Honest communication is a good way to either confuse non-technical users or piss them off. As for my assumptions, see [this comment](http://programmers.stackexchange.com/questions/303997/how-to-deal-with-a-bug-which-seems-to-have-fixed-itself?noredirect=1#comment635441_303997). I don't really see the point of arguing semantics here. – Lilienthal Dec 01 '15 at 18:37
  • Voting to close as primarily opinion based. There's quite a few possible approaches to resolving this issue, all of them equally valid depending upon the environment you're working within. –  Dec 01 '15 at 18:46
  • The question was locked when it was closed, because it was a failed migration (from the Workplace). I have cleared the migration, which also re-opened the question. I do not necessarily agree that this is "primarily opinion-based", but since that's what the community decided I'm restoring the closure. – yannis Dec 02 '15 at 07:47
  • I totally agree with "The goal here is to get them to shut up". If keep communication, it wastes too much resource on it. The key word of this question would be "no longer reproducible" which seems to be fixed. – Ben Cheng Dec 02 '15 at 15:31

3 Answers3

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

Community
  • 1
ratchet freak
  • 25,706
  • 2
  • 62
  • 97
  • 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 01 '15 at 15:35
  • You run the risk of spending several hours on deciding that the bug was already fixed as a side effect of something else, or of not finding anything conclusive at all. I think most people would decide to wait until it is seen in the wild again. – RemcoGerlich Dec 01 '15 at 15:37
  • 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 01 '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 01 '15 at 16:47
  • 7
    Problems that go away by themselves come back by themselves. – Pete Becker Dec 01 '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 02 '15 at 09: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.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176