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.