|
Re^4: Sometimes, just saying "Thank You" is not good enough
by Anonymous Monk on Jun 15, 2010 at 19:59 UTC
|
If it can't be repeated, it never happened.
| [reply] |
|
|
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] |
|
|
Re^4: Sometimes, just saying "Thank You" is not good enough
by Anonymous Monk on Jun 16, 2010 at 16:01 UTC
|
So someone reports test failure in your module, it just says "not ok" or "Unknown error", and your solution is to close the bug, because someone else with more skills/experience will report it sooner or later.
You're the one who wrote the failing test which doesn't hint at the problem, maybe you should write a better test. | [reply] |
|
|
There's a huge difference between "Hey, your test number 47 failed." and "It doesn't work".
Even if it's the first case, the reporter should be able to tell me, at least upon request, what version of Perl and what operating system he/she has. My test scripts tend to print some info about the environment at the beginning, but it's definitely not sensible to repeat that info with each and every failed test. So even "your test number 47 failed" is not a good report. "I tried to build your module and the tests failed, here's the test output ...". That's the one I want. On the other hand ... how often do you get a notification about your tests failing and how often do you get an email about some script (often not included) not working with your module? I was talking (mainly) about the later!
Jenda
Enoch was right!
Enjoy the last years of Rome.
| [reply] |