How to differ between QA and Tech Support bug issues?

EdDev_Gilat April 21, 2013

We are currently evaluating JIRA and going to use it to manage a release cycle.

I've encountered a dilema, on how to differentiate between a reported bug from QA and from Customer Services.

The following options came to mind:

1. Create a different issue type for each.

2. Use a selector field to set the origin of the issue (where it was found: QA LAB, CS LAB, Customer Production... etc).

3. Same as 2, just use a LABEL.

Main consideretions are reports, statistics and ease of creating an issue.

I will apriciate your advice and experience on this.

Thanks,

Ed.

2 answers

1 accepted

2 votes
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 21, 2013

I'd add "separate projects" to your list - it may not be appropriate, but I don't know your process and organisation, so it's worth mentioning.

Personally, I'd also rule out option 3, as humans set labels, and we can't type, or remember to do it reliably. That kind of applies to 1 and 2 as well (we pick the wrong issue type, or the wrong item from the select list), but with those two mistakes, we are at least limited in how badly wrong we can get it. For example, if you've got 4 issue types or four "origins", the worst case is I pick the wrong one. If you have labels A, B, C and D for the origins, there's nothing stopping me writing "Penguin" for it.

I'd also prefer to use "issue type" to represent the type of problem, instead of "where it was found". Again, that's a purely personal preference, but I think it saves you some effort in explaining that "issue type != type of issue"

Finally, on option 2, a couple of extra tweaks

1. You could use components if you don't want a whole new field. Although I don't think components really are for that and probably have better uses.

2. If you indulged in a little coding, you could do sneaky stuff with the field - leave it off the "create" screen, and set it in code. For example, if your users are in distinct groups or roles, you could write some code that says "this human is a QA bod, so stick QA LAB in this field"

1 vote
Henning Tietgens
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 21, 2013

The easiest way for creation is to differentiate by the reporter or the group of the reporter, if this is possible.

If you want to use issue statistics, you should use a select list with predefined values or a different issue type. More issue types means more administration if you want to change the screens or workflows etc...

If there are only some values and they don't change very often I would not suggest to use labels, because you can't control the possible values and each user can create new one.

Henning

Suggest an answer

Log in or Sign up to answer