22

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)
Improve this question
8
  • 8
    Too Localized ;)
    – yannis
    Commented Apr 10, 2013 at 11:23
  • 4
    disagree this is too localised, it may be better fit for SO though as its possibly tool specific
    – jk.
    Commented Apr 10, 2013 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
    Commented Apr 10, 2013 at 11:27
  • 2
    @YannisRizos doh! perhaps it should have been an answer then ;)
    – jk.
    Commented Apr 10, 2013 at 11:29
  • 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
    Commented Apr 10, 2013 at 11:34

4 Answers 4

Reset to default
28

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.

Improve this answer
7
  • 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
    Commented Apr 10, 2013 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.
    – user82096
    Commented Apr 10, 2013 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
    Commented Apr 10, 2013 at 13:32
  • 1
    All the answers are good, but this one seems to nail it. Thanks everyone.
    – Benjamin Gruenbaum
    Commented Apr 10, 2013 at 15:26
  • 6
    How about "Fixed by Redesign"?
    – penguat
    Commented Apr 10, 2013 at 16:09
48

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

Improve this answer
1
  • +1 if you cant add it at least choose as it as not a bug and comment why
    – tgkprog
    Commented Apr 17, 2013 at 5:31
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.

Improve this answer
6
  • 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
    Commented Apr 10, 2013 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.
    Commented Apr 10, 2013 at 12:10
  • 3
    @YannisRizos: Fixing meta-bugs using bugs. How cool is that!
    – Jörg W Mittag
    Commented Apr 10, 2013 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.
    Commented Apr 10, 2013 at 12:47
  • 2
    @Yannis. I'd lose sleep over that: overtaken should be one word.
    – TRiG
    Commented Apr 10, 2013 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.

Improve this answer
2
  • 3
    Fixed by sobering up and checking again <- true story.
    – yannis
    Commented Apr 10, 2013 at 13:58
  • 1
    Jira allows for this approach as well. Just mention the issue number in the resolve comments and Jira will turn it into a hyperlink.
    – Marjan Venema
    Commented Apr 10, 2013 at 17:57

Not the answer you're looking for? Browse other questions tagged or ask your own question.