Tracking various bug types in Jira - single or multiple issue types?

[Radek Janata]

Hi Community!

In majority of our Jira projects our development and QA teams track various bug types in our Jira - issue types are Functional Bug, Localization Bug and Documentation Bug. Loc and Doc bugs are separated mainly because of they are resolved by independent Localization and Documentation teams (regardless which project these bug types are located in).

Btw, all bug issue types have same workflow and more or less same screens and fields.  The main goal to distinguish them is just fast visual bug type recognition and assigning them to the right teams to fix.

In other (simplified) projects, teams are satisfied with simple Bug issue type only. These projects are not product related and therefore no localization or official documentation is needed.

There's been recent request to extend the bug type portfolio - Performance Bug and Security Bug (and hopefully not too many other bug types in future). Again, same WFs and almost the same fields/screens.

---

There are two approaches in my mind:

1. Add another 2 new issue types (and I will hope that no new bug types will be needed in future).
2. Unify Bug issue type usage across the company and start using single Bug issue type with Bug Type custom field.

If I'm on "green field" I would prefer #2. I'm aware of slight field/screen differences but this is something we can handle using ScriptRunner Behaviours or some injected JavaScript on front-end.

With existing Jira instance (with 90k+ of various bug issues) changing the whole concept would be more complicated - updating all JQLs in filters, boards, Jira macros in Confluence pages etc. However, I have several internal tools already prepared that would help to automate all these tasks, so this is not a blocker.

---

I've very interested how other development/QA teams handle various bug types in their environments.

• Do you use a single Bug issue type only? Do you mark various bug types with some label or custom field?
• Or do you have set of separate issue types? How many of them? How are you satisfy with this approach?
• What advantages/drawbacks you see on your setup?
• Is there anything you would change on your current setup today?

Thanks for your comments and thoughts.

Radek

[Leonard Chew]

We have one bug type "Bug" and several fields describing the bug, such as "Technical Origin", "Business Domain", "Caused by" Issue-Link, "Raised by" (Customer or internallly), and too many fields more.

I'm happy with only one bug type and don't see any reason for us to use different bug issue types, especially if the workflow is always the same, but there is no right or wrong, just different ways in approaching the problem. 

Our products are split into (own developed) libraries (UI components used in serveral products, or a framework used in several products), which all have their own jira-project.

Customer bugs are always raised in the end-product. If it turnes out to be that the bug lies within a library, an additional bug is raised in the library project (blocks first bug). The library bug is solved in the new library version(s) and the product bug is afterwards solved in the product version (using the new library version). 

In my opinion we have too many fields describing a bug, which results in the fields not being populated by everyone in the same manner. I'd rather have less, but more meaningful fields.

[Radek Janata]

Thanks for the reply. We actually have very similar project structure.

I like the part of having two separate bugs - one in end-product (bug from customer POV) and another in library project (bug described more from developer POV). Most probably both bugs are linked together. Btw, how do you handle that the end-product customer bug is marked as resolved after the library bug is resolved? Any smart automation behind?

And I also like the "caused by" issue link. I've been thinking of it too but was not sure if it's good idea or not. I'll reconsider it and open the discussion with our dev/qa teams.

[Leonard Chew]

Using two separate bugs works well, if you use versions, and is in my opinion a must, if the library is used in more than one end-product.

The typical use-case would be:

1. customer opens bug in end-product
2. product team discovers the bug is in the used library
3. product team opens a library bug (issue link: blocked by)
4. library team resolves library bug and makes a new library version (!)
5. product team upgrades the library in the end-product to the new version and checks if the bug is resolved
6. product team resolves end-product bug and sets the new end-product version
7. customer gets the fix when they upgrade to the new product-version

The customer does not need to know anything about the library version, only of the product version he is currently using.

The "caused by" link needs a bit time to unfold its value, but after a while is good for analyzing which project (or issue or bug) caused a lot of maintenance, so that ppl know where to be careful to change things. Also for the product owner to have some proof to add extra budget to the quote of a new feature if it is in a "dangerous" area.

[JP _AC Bielefeld Leader_]

Hi,

I would only create different issue types, if there is a really specific need for it, eg. different workflow, etc.

I like the component concept in Jira, that allows tagging an issue from the end user & developer side.

All issues created by the end user are tagged with component "end-product". Then this is checked by the first level support. If it's an error on the dev side, it might be tagged with an additional component "lib-bug". Depending on your environment, you can automatically create linked issues in other projects (dev?) and auto assign dev people there, based on the set component (Components allow an auto assign to specific users w/o any programming).

So imho, without the need of really different workflows, keep it simple & just use one "Bug" issue type.