Category: bug tracking

Total 4 Posts

Atlassian Stimulus Package – Offer Expires April 24, 2009

I just got this in my inbox — quite a deal if you are looking to tryout JIRA or Confluence.

For this week only, we’re offering a special 5-user “starter” license of JIRA and Confluence for only $5 each. We’re calling it the Atlassian Stimulus Package and it’s our way of supporting small teams and small businesses in this difficult economic environment. Best of all, we’re going to donate every penny to charity, so please help us spread the word!

The Atlassian Foundation is donating all proceeds to Room to Read, a charity that helps the world’s future entrepreneurs by building libraries and schools for children in developing nations.

Get all the details at www.atlassian.com/starter. Hurry, offer ends on 24 April 2009.

 

By - On 2009-04-20 - in bug tracking, IT, jira, test tools

Bug Tracking – Possible Resolution States

I have used multiple bug tracking systems. Most have support for a basic lifecycle that works in most cases. When a bug is resolved, there is varied support for how the bug was resolved. For example, FogBugz, for a bug, has the following resolved states:

  • Resolved (Fixed)
  • Resolved (Not Reproducible)
  • Resolved (Duplicate)
  • Resolved (Postponed)
  • Resolved (Won’t Fix)
  • Resolved (By Design)

Bugzilla uses the following resolution reasons:

  • Fixed
  • Duplicate
  • Won’t Fix
  • Works For Me
  • Invalid

Jira has the following default resolutions:

  • Fixed
  • Won’t Fix
  • Duplicate
  • Incomplete
  • Cannot Reproduce

As you can see, among these three products, most of the resolution states are supported across these various bug tracking solutions.

When I was at Aldus, we had a set of resolutions which gave more detail as to why a bug was not fixed. I still find myself referencing these abbreviations (and ones I added) when I am working with bugs:

  • Fixed
  • DUP – Duplicate
  • CNR – Cannot Reproduce
  • NAB – Not a Bug
  • NOB – Not Our Bug
  • NLAB – No Longer a Bug
  • NTBF – Not to be Fixed

A resolution of DUP should reference the appropriate ID(s) of the bugs which this one duplicates. NAB should state why – by design, misunderstanding, etc. NOB is useful when using components from other vendors and the decision is made not to work around an issue in the component. NOBs should be reviewed periodically to see if fixes are available from the component vendor. NLAB occurs when a feature is descoped or reworked so the bug is no longer applicable to the product. Finally, NTBF is used to remove the bug from the active list. NTBFs from prior releases should be reviewed at the beginning of a project. In addition, NTBF bugs in the current release need to be reviewed periodically to make sure the resolution is not being used too aggressively.

 

By - On 2009-04-11 - in bug tracking

BestBrains – Why Bugs Should not be tracked

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.

 

By - On 2007-09-30 - in bug tracking

Jira Priority (vs. Severity)

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…)

By - On 2007-01-02 - in bug tracking, jira