Yes.

While it is tempting to just leave this entry as a single word, lets use go into the subject a little deeper.

From the Test perspective:
A lot of new testers will find themselves asking this question either to themselves or a more seasoned member of the group fairly often, though it may not be phrased exactly as such. It is most commonly disguised as “I’m not getting the behaviour I expect, but I think it is my fault. Should I go talk to developer X about it?”. In any situation you get something you don’t expect there are exactly two possible reasons for it (every other reason can be rolled up into one of these):

  1. There is a bug in the software
  2. There is a bug in the documentation

By their very definition a bug needs to be logged in either case. Notice that these are pretty broad categories. I have specifically not said “end user documentation” or “customer shipping software”. It could be that your test harness is doing something funky or a design document is hopelessly out of date. Neither one of those things a customer should ever see, but they are important parts of the overall Quality of the product so must be tracked. The challenge then to the reader is to come up with something that might stall test or otherwise cause test to go elsewhere for clarification that is not a bug (that is, cannot be abstracted to the categories I have defined).

Another way of answering the question that started this all off is with another question: Am I having any issue with what I am presently experiencing? This is of course a loaded question as you would not be asking it if you were not.

From the Developer perspective:
The developer perspective is half of the inspiration for this topic being covered instead of what I was going to talk about.

A developer should log a bug every time they see/do one of the following:

  • They are implementing a new feature / bug fixing and notice a yet-undiscovered problem at the code level. Yes, it might take you less time to just fix the bug, but you must log it anyways. Why? Because how else are you going to put in your code check-in note the associated bug number. Every change commit that deals with your code base must have an associated bug or feature number. (Rules you should have for your versioning system is a topic unto itself)
  • As soon as you finish writing in your code a comment that has anything remotely similar as TODO or FIXME in it. I call these ‘developer notes’ as they are notes by developers for developers. Every TODO or FIXME in your codebase must have an associated bug number. I recommend having a standard format for these notes which will allow for easy parsing of your code by code analysis tools. Perhaps something like this would work in your environment.
    <br></br>/* TODO<br></br>user: adam<br></br>bug: 000001<br></br>description: to something clever instead of horrifically hacky here */<br></br>
    By having it in both places, not only is product management aware of the issue you have spotted, but the next person in the code will have a bit of a pointer about how something should be implemented and/or its implementation level.  Once I remove the bits that are specific to our product from the script I use to see these developer notes, I will put it up for grabs and point a link to it.

But what about Security?:
The sensitivity of the bug is the other half of why this is being written. This affects both developers and testers. What if you found a bug that had some serious serious ramifications? Like say “the private key of component x is 12 bits long instead of 8”. Its a super easy fix; just add the missing 8. Should you log it? Absolutely. Would the bad guys compromise your product in minutes if they saw this? You bet. But notice how I did not say you needed to make this bug public? Some organizations have polices around their bug system such that “No security related bugs can be entered in the bug system.” This is dumb on so many levels.

  • So what you are saying is that it is a bug, but cannot be in the bug system? How are we to track it then? Email? Sticky notes? Morse code on an abacus? As soon as you track a bug a different method what you have created is a supplementary bug tracking system. But as soon as you do that then you break the rule saying that security bugs cannot go in the bug tracking system. Let the recursion games begin…
  • Security through obscurity has been proven to be ineffective time and time again. Not putting security bugs in the bug tracking system is just another form of this
  • Not putting the bug in the tracking system also fails the “What if developer X is hit by a bus tonight on the way home from their weekly curling match?” check. If the person who has the record in their head is suddenly removed from the scene, how is the issue going to be resolved?

“But I will look dumb if I log it”:
Who cares. You will look dumber if it comes up later as an issue and you say something along the lines of “Oh ya, I remember seeing that.” Besides, everyone who is new to a product, regardless of how senior they are in their QA career is going to log dumb bugs at the onset. What makes you a good QA person is to learn from your mistakes and not log eight or nine permutations of the same bug.

This was written in three different stages with three differing levels of distraction so the continuity might not be nearly as good as I wanted, but I here is what to take home:

  • Disk is cheap, so log everything.
  • Stop thinking as your bug system as a “bug” system, but more of an “issue” system (“I have an issue with feature X, and it is blah” where blah could be a requirement breach or no testing hooks)