Flex JIRA Tips (part V) – What does it mean when my bug is ‘Deferred’?

Deferred bugs is a tough topic. Someone is always unhappy because it means that a bug is valid and still exists in the our product. When you see that a bug you filed has the status “Deferred”, it means that we will very likely not fix it in the current release that we are working on. For example, bugs that are currently in “Deferred” status will probably not get fixed in Flex 4 (Gumbo). In fact, we may never fix it. Ah…it hurts me to say that, but, I’ll be honest.

In each release, we usually look at deferred bugs at the beginning or a few months in. We will take some time out to review what we might want to open for the release. This sometimes happens multiple times. We will likely look at bugs with the following characteristics:

1. Regressions – Bugs that broke something in an older build.

2. Votes – Bugs with a lot of votes.

3. Date filed – Because we are more aggressive about deferring bugs at the end of a product cycle, we might have deferred more severe bugs. Therefore, we usually revisit all the bugs logged a few months before our last release.

4. Bugs brought to our attention by customers. – We usually hear about bugs if people have blogged about it and word has spread or if our Adobe Support team brings it to our attention.

So, now that you have an idea of the bugs that we’ll consider re-opening after they have hit the “Deferred” status, I’ll talk a little about why we defer bugs. There are many, many reasons and my opinion probably differs from the other voices on my team. (Remember, this is not an official Adobe blog 🙂 ).

Reasons we probably differ a bug:

1. There is a workaround. Some of you hate this word, but, honestly, we are more likely to fix bugs that people cannot get around and may be blocking their development.

2. Few votes. If no one has commented on a bug or voted for it, it looks like not too many people care about the bug.

3. It seems like a corner case. We often get bugs that are very hard to reproduce because they only happen in a scenario that is very specific to one person. In other words the “discoverability” is low. This brings up the important point that all bugs should have an simple reproducible case attached to them. This makes figuring out a bug easier.

4. It has existed for several release (combined with #2).

5. It is late in our product cycle and the fix is risky.

Being in QA, my team has filed a lot of bugs, and like others, our bugs are often deferred. It hurts, I know. I wish our developers could fix every bug that comes to our team, but, the reality is that there are too many. I personally know that our Internal Review queue is pretty high right now because we are deciding what bugs to open and what to defer. My QA manager and I were just discussing how hard it is to tell someone (in a bug) that we just can’t fix it right now.

3 responses

  1. Great post Joan!

    There just simply isn’t a way that everything can get fixed.. it’s just the nature of software… there will always be bugs.

    A group of us members in the community are currently planning an event to try and knock out as many bugs as we can.


  2. […] Flex JIRA Tips (part V) – What does it mean when my bug is ‘Deferred’? […]

  3. 4. It has existed for several releases

    My god, I can’t believe that’s considered a reason for deferring a bug. That should be a reason for giving it more priority!!

    That explains a lot of things, however.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: