While some devs probably find this an acceptable, even humourous attitude, end-users who are stuggling to explain a bug they've run into may feel infuriated if that's your response.
I know as well as you do that fixing a bug that can't be reproduced is near on impossible sometimes.
For those not familiar with testing in general, if you can't reproduce a bug, how can you:
(a) identify the bug ?
(b) fix it ?
and
(c) prove that you've fixed it?
Internally, its fine to joke around and say "it never happened" but all reports for this "phantom" bug need to appended onto the original bug report. If the bug truely exists, eventually, you'll have enough dots to draw a line between them and identify the bug...
| [reply] |
This is completely untrue - there are lots of things that cannot be repeated but definitely happened - like your birth, for example. This statement shows no respect for the vexing but important Heisenbug, or the fact that there are edge cases that are difficult or impossible to replicate, but still happened.
Most importantly, when you don't know what you're doing, you don't know what you did, but there may really be a bug there.
| [reply] |
False analogy. 7 billion hairless apes on the horizon show that bug is trivial to reproduce.
I agree it's important to be sensitive to users and their inability to describe problems well and the possible shortcomings in documentation and UI that exacerbate the situation but when you hit a bug that is impossible to reproduce the chances it was PEBKAC are 1,000 times greater than it being some mystery that must be solved and justifies chasing for a few hours or a few days.
If it's really not reproducible given a good try, split the difference. Drop some new test and logging around the reported area if it makes sense to try and tell the user you're investigating further. (This advice is not pertinent to banking and medical applications where bugs could possibly mean prison time or dead patients.)
| [reply] |
| [reply] |
