September 30, 2007 by mensming.

I came across a reference to this article - Why Bugs Should not be tracked by Lars Thorup- and its title intrigued me. While I disagree with the conclusion - I found that I agreed with much of what was said. It is a very quick read - rather than summarize I would suggest reading it now.

My first disagreement with the article is the premise that many of the problems with bug systems is the result of a heavy process. I believe that the problem Lars articulates are symptomatic of an ineffective process or no process (at least in regards to bugs) at all. My second problem with the conclusion is that it is developer centric. While a developer may not find value in writing up a bug (especially if they can fix it immediately) there may be value to other team members who need to verify the fix, evaluate the impacts, support older versions, etc.

All of that being said, the recommendation that the backlog of open bugs should be minimized is a good one. My feelings on this topic have become stronger recently. I believe that if you do not have a target release for a bug after it has been open for a few weeks, then it is better to close it out as not to be fixed (NTBF). Bugs can always be reopened and I would much rather have a manageable list of working bugs then a comprehensive list of every bug ever opened but not resolved.

Posted in bug tracking | No Comments »

January 2, 2007 by mensming.

One of the first things I show a new tester is our bug tracking system (currently a modified Bugzilla - however, we are in the process of migrating to Jira). During this orientation, I discuss the difference between severity and priority. Severity is the subjective rating of how bad an issue is while priority is a decision of how quickly the bug should be addressed.

Bugzilla supports priority and severity out of the box. Jira does not support severity out of the box. My complaint is the default values supplied for the priority field:

Blocker - Blocks development and/or testing work, production could not run.

Critical - Crashes, loss of data, severe memory leak.

Major - Major loss of function.

Minor - Minor loss of function, or other problem where easy workaround is present.

Trivial - Cosmetic problem like misspelt words or misaligned text

To me, these are clearly severities and not priorities. (To be fair, Jira makes it easy to customize the priorities.) It is also true that generally, the more severe an issue is the higher priority it will have. The counter example I usually use is what happens is the company name is misspelled on the product splash screen. This is a low severity issue. However, in most companies I have worked for, this is a high priority issue to fix (especially when a demo before the executives is scheduled…)

Posted in jira, bug tracking | No Comments »