How to keep long term active issues in JIRA without seeing them as Unresolved?

Question

I think I may have discovered an essential design flaw in JIRA.

If you try to host Test Cases, Inventory / Assets or other long term items in JIRA, you will face this problem.

* As a general rule we consider any ticket with Resolution NOT EMPTY as being actionable. That's essential to have a company wide simple filter for defiing actionable items.

* You don't need to action (do something) on active Test Case, so their default state should be one that have some kind of resolution set like "Resolution = Active".

* JIRA and Confluence will display all tickets with a resolution with a crossed line, which is missleading for all these type of actions.

How can we solve this problem? Clearly we do want to endup with a very complex set of fitlers .

Update: It seems that the newlu introduce category of the status (color) is more likely to be the better way to distinguish between active/actionable issues and non-actionabile ones.

Still, as far as I know there is no way to filter issues based on this.

Nic Brough -Adaptavist- · Answer

Yes.  Separate system or project might not work, it does depend on the usage (although the place I've seen test plans done in Jira were very happy with doing it by project - in fact they had several projects full of test plans.  It worked perfectly for them with tens of thousands of plans.  But I digress.)

If you're going to keep them in the development projects, then I'd recommend having a distinct workflow for test plans, one that makes them clearly stand out from the other issues.  Have different status for them, and, obviously, only set the resolution when you're saying "this test plan no longer applies, close it".  It could be as simple as "Active test plan" and "Redundent test plan"

Sorin Sbarnea ( · Answer

Thanks Nic,

People do want to keep test cases and other types of similar tickets in jira, tickets that are normally in a non-actionable state.

I am looking for a simple way to define this. Filtering by project is not an acceptable option, as it does not scale. I need a solution that would scale. At this moment I am starting to think that I willl have to add the "Test Case" or "Inventory" issue type as an exception.

Nic Brough -Adaptavist- · Answer

That's not a design flaw, it's an incorrect usage of the resolution field.

If you want issues to stay open, do not resolve them, it's as simple as that.  For the test cases, I'd put in a workflow that indicates what they are.  Ideally, you'd keep them separately from other issues - at the very least in a separate project and quite probably in another system that is built for handling test cases.

Still, excluding things like Test Cases or Inventory does bring another probem: sometimes these can be in an actionable state, like in-service, or a test-case that is broken or needs rework. If I exclude them by issue type, I will miss this information.

I am looking for a global solution, one that would be easy to document and that will still allow us to generate some overall statistics across all hosted projects (that's all, not as in a manully managed list).