April 20, 2009 by mensming.

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.

Posted in IT, test tools, jira, bug tracking | No Comments »

April 18, 2009 by mensming.

In a prior post, I described an example of a side effect of a feature that our users came to rely on as a feature in its own right.

While reading Raymond Chen’s The Old New Thing: Practical Development Throughout the Evolution of Windows, I came across what I consider the mother of such side effects. In an essay entitled “The hunt for a faster syscall trap”, Raymond describes how an Intel representative was perplexed when a Windows engineer requested speeding up the fault when an invalid instruction is executed. This would seem to imply that the Windows code was buggy in some sort of way. The story goes on to relate that executing an invalid instruction was intentional - as a way to get into the CPU kernel mode.

A version of the essay can be found online here.

Posted in software engineering, system testing | No Comments »

April 11, 2009 by mensming.

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.

Posted in bug tracking | No Comments »