How to differ between QA and Tech Support bug issues?

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

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 Community Champion Apr 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 Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,314 views 14 20
Join discussion

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot