21

I'm currently on a medium-sized team of web developers. We're using jira for bug tracking.

We're working on a product with frequent layout changes. A lot of times bugs are filed about a bug in the layout in some browser. Sometimes, by the time we get around to dealing with a low priority bug, the layout has already changed and it is no longer relevant.

  • What should we close it as?
    What I mean is how we should treat these issues? While Jira is the bug tracking software we use, I'm more interested in how to handle these sort of issues in general.
  • Does it even matter? (We might return to the layout later, but it's very unlikely)
Community
  • 1
Benjamin Gruenbaum
  • 5,157
  • 4
  • 24
  • 34
  • 8
    Too Localized ;) – yannis Apr 10 '13 at 11:23
  • 4
    disagree this is too localised, it may be better fit for SO though as its possibly tool specific – jk. Apr 10 '13 at 11:25
  • 6
    @jk. Heh, I meant "too localized" as a suggestion / answer to the question, not that the question itself is "too localized". If I thought the latter, I would have just closed it. – yannis Apr 10 '13 at 11:27
  • 2
    @YannisRizos doh! perhaps it should have been an answer then ;) – jk. Apr 10 '13 at 11:29
  • layout change has fixed that bug (although inadvertently) => the correct resolution is fixed. The fact that fix is a side effect of layout changes is worth pointing out in comments, so that ticket readers could understand what happened – gnat Apr 10 '13 at 11:34
  • 6
    @jk. I think the second question is the more interesting (does it even matter?) but I don't have time right now to answer it (and I'm not really sure the answer that's forming in my head is a good one). As for the first question, if this thread becomes a "word/phrase suggestion" one, it might get closed as "not constructive". So, answerers, don't ignore the second question please, that's the on-topic and interesting one. – yannis Apr 10 '13 at 11:34
  • 1
    Thanks for the answers, they're both helpful. @YannisRizos While admittingly the second question is more interesting, I don't think the first one is not constructive. What I meant by Choosing a word isn't about choosing between two similar terms, what I meant was we should _treat_ these issues. While Jira is the bug tracking software we use I'm more interested in how to handle these sort of issues in general. While I'm on SO much more often than I'm here, coming from SO this question seemed like a better fit here to me. If you feel differently you're welcome to do whatever you see fit. – Benjamin Gruenbaum Apr 10 '13 at 11:53
  • 1
    @BenjaminGruenbaum I was explaining why my suggestion is more of a comment than an answer and encouraging other answerers to only answer in full and not skip your second question and turn this into a word game. That hasn't happened yet, but it has happened in the past on similar questions, and I hate it when we have to close questions (mainly) because they are getting a lot of sub par answers. Perhaps you could work your comment into the question text and help answerers understand that you aren't just looking for word suggestions. – yannis Apr 10 '13 at 11:58

4 Answers4

47

We resolve such issues as 'Obsolete'. This is not a default resolution option in JIRA but it is easy enough to add.

Kris
  • 1,322
  • 1
  • 9
  • 13
27

Nuances like that matter if you consider issue tracker as a means to communicate the status of problems that were reported in the project. For that purpose, it makes sense to invest some effort into ensuring that bug report is easy to read and understand.

This situation gets much less confusing if you look at it from a perspective of a tester. If your team doesn't have a tester, imagine one (or better yet, hire one 1, 2, 3).

Okay, so there was a bug once upon a time, tester can reproduce it using older releases of your application (side note in unlikely case that you don't keep copies of older releases, then you've got much much harder problems in your team than obsolete bugs). Tester can see it and can tell what's wrong, what is it that makes it a bug.

Now you say, "layout has already changed and it is no longer relevant" - the high-brow no longer relevant turns in tester mind into much simpler statement: the problem has gone.

  • It is important to note here that professional tester should be comfortable thinking of the system as a black box. From that perspective, it doesn't matter much how exactly it happened that problem has gone, it could be layout change or black magic or total redesign, or concrete code change, whatever.

From black box perspective, your situation is pretty simple. There was a problem, it's still reproducible in older release, now you claim that newer release has no such problem anymore. For a tester, this boils down to a claim that bug is fixed and, respectively, to the need to verify whether the claim is true.

Professional tester would take your older release, look at how problem is present there, then take newer release and check if it is gone or still there.

From above, the most accurate way to handle bugs like you describe, would be to close these as resolved, fixed. Of course it wouldn't hurt if you clarify in the comments that the fix occurred as an unintended side effect of layout change.

One of customized JIRAs I used to work with in a past project had resolution "Fixed By Design" to communicate rather profound changes having lots of consequences, some intentional, some not. For case like you describe, that could be also considered instead of plain "Fixed", since it hints ticket reader on that it's more of a side effect rather than intentional code change.

Community
  • 1
gnat
  • 21,442
  • 29
  • 112
  • 288
  • 2
    *Fixed by Design* would imply, to me, the complete opposite of that. In my mind, *by design* means "intentional" (it's the opposite of "by mistake"). – TRiG Apr 10 '13 at 13:24
  • I agree that "fixed" is sufficient. It doesn't matter at all whether it was intentional or a side effect of other changes. However, I also agree with @TRiG that "Fixed by Design" is confusing. –  Apr 10 '13 at 13:32
  • 1
    @TRiG well that's why I pointed that one better explains exact details in comments. Fixed By Design is a bit broad; in the project I've seen it it was used to communicate rather profound changes having lots of consequences, some intentional, some not - thus covering cases like that. Note also, neither question text nor my answer imply "fix by mistake" (what mistake?) - here, "unintentional" is much _much_ better fit – gnat Apr 10 '13 at 13:32
  • 1
    All the answers are good, but this one seems to nail it. Thanks everyone. – Benjamin Gruenbaum Apr 10 '13 at 15:26
  • 6
    How about "Fixed by Redesign"? – penguat Apr 10 '13 at 16:09
  • -1 because I disagree with nearly everything you said. +1 because I agree with the final conclusion, "close these as resolved, fixed. Of course it wouldn't hurt if you clarify in the comments that the fix occurred as an unintended side effect of layout change". The whole claim about testers not understanding the difference between fixed and no longer relevant is absurd. So what if it's a black box. It's still obvious to a tester there's a difference between "problem is gone because it was fixed" vs "problem is gone because it's no longer possible to create the context where it had existed". – Ben Lee Apr 15 '13 at 20:38
  • @BenLee to reason about things _as if black box_ is only a technique, one (of many) tools in QA arsenal if you wish. Testers using it aren't prohibited to have an interest and understanding of internals of system under test (using deep understanding of system internals to derive better "black box" test scenarios from code coverage results analysis is a good example) – gnat Oct 09 '13 at 14:03
9

JIRA (and I'm sure other bug trackers) allows you to specify custom resolutions so you should be able to set up a "Overtaken By Events" or "Irrelavant" resolution, or similar to allow you to express the closure how you want

Does it matter? that depends, for us I'd say yes as our customer is overly concerned about the number of open issues in our tracker, so for us its useful to be able to say these are closed because they are no longer relevant without deleting the issue entirely.

Even without a customer concerned by issue numbers, pruning old open issues that are no longer relevant is definitely useful just to reduce clutter in the browser.

jk.
  • 10,216
  • 1
  • 33
  • 43
  • 1
    "Over Taken By Events" is too long (imho), I'd go with a single word (irrelevant/obsolete) just because it's easier to search and takes less space (in reports, etc). The one time knowing the amount of our obsolete bugs was useful was when they were coming in in bulk, and that pointed to a communication problem. Our testers were not up to speed with what our developers were working on, they had missed the memo that things will be flaky for a week or so and were making (useless) noise. So, looking back at our obs. bugs helped us find and fix a hole in our communication processes. – yannis Apr 10 '13 at 12:06
  • 3
    we actually use an acronym OBE, but I think the actual word used is the least interesting point here, the point is to pick something that works for you – jk. Apr 10 '13 at 12:10
  • 3
    @YannisRizos: Fixing meta-bugs using bugs. How cool is that! – Jörg W Mittag Apr 10 '13 at 12:13
  • @YannisRizos search isn't much of an issue as the valid resolutions are chosen from a drop down anyway (in JIRA) – jk. Apr 10 '13 at 12:47
  • @jk. I'm a JIRA user as well, and I love composing custom queries for issues, and digging further into our bug database than just relying on the premade reports. That said, the length of the custom resolution name is not really an issue, more of a personal annoyance when it's too long. I could certainly live with your OBE acronym, and I would certainly not lose any sleep if "Over Taken By Events" or something longer was chosen. – yannis Apr 10 '13 at 12:51
  • 2
    @Yannis. *I'd* lose sleep over that: *overtaken* should be one word. – TRiG Apr 10 '13 at 13:26
5

We use FogBugz, but I'm sure the same (or similar) applies here:

We just use "Resolved (Fixed)" and comment in the resolution edit something like "Fixed by case 12345".

FogBugz matches "case \d+" and links the two together under Related Cases, but if Jira doesn't do that, it should be simple to just add a link.

This is IMO better than a "Too Localized" variant because it was an actual bug, and better than just "Obsolete" because it was fixed, that feature wasn't just removed.

Izkata
  • 6,048
  • 6
  • 28
  • 43