I am an entry level tester and been experiencing new things about testing everyday which is great. So I am thinking, how do I deal with an intermittent bug since its most likely that developers wont be able to reproduce the error. Should I file it still for the record?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Yes, by all means - you must write a bug report! In your report, note that the bug is intermittent, and leave comments about your investigation, what you have done to try and reproduce the problem, and any other clues you can think of.
Perhaps it turns out not to be an important bug, or not to be an actual bug at all. In that case, it has only cost you a little bit of time.
The only way you can lose here is to not write a bug report, only to find out later that it was indeed an important bug. Imagine that the VP of Client Services comes to you and says that an important customer has this bug. Then she asks you why you didn't find it first. Are you going to be happy to say "Well, I did find it, but because it was intermittent, I didn't bother to file a bug report"? Yikes!
Here's more on my thinking: http://www.allthingsquality.com/2010/04/non-reproducible-bugs.html
And here's an excellent article from James Bach about How to Investigate Intermittent Issues: http://www.satisfice.com/blog/archives/34
Log the bug.
Firstly, it's often turns out to be useful to have a record of the bug. If the bug manifests itself on a customer's machine at some later point (perhaps months later) and it suddenly becomes important to fix it, at least you've got somewhere to start from.
Even if the developer cannot reproduce the bug, they may be able to add extra logging that will help identify the cause if the bug appears again. They may also be able to review their code and identify the cause that way.
You should certainly log the issue, probably with the word intermittent in the title and perhaps a keyword/tag specifically for these kinds of bugs (depending upon your defect tracker).
In addition to the steps taken to recreate this bug, because so many of them depend on what you did before the particular operation that triggered the bug, try to capture as many of the steps you can remember between your fresh session and the bug.
For example, instead of just associating the bug with the Edit a Comment function with the steps associated with what post you commented on and what text you entered in the comment, try to frame it with some of the things you did before that (I visited the site, I logged in, I looked at my profile, I changed my avatar, I clicked a like and then clicked the unlike, I added a comment to post A, and then I added a comment to post B and the error occurred.
These valuable details might help establish a pattern, especially if you revisit the report and add this path every time it occurs.
Some Friday, when you've got an hour to kill until quitting time and your desk already sparkles, you might want to look for these kinds of bugs and see what sort of pattern emerges over time.
Oh, and for Pete's sake, don't let them close intermittent issues as not reproducible.