Resolution status in Test issue different between imported and mannually created test

[Cláudia Dias]

So my company is recently using Jira and Xray. We have a workflow defined for all issues, including for Test issues. In this workflow we have a status that has a resolution of DONE associated. While going through the list of tests in a project, we noticed that some tests were in different status of resolutions, even though being in the same workflow status.

After some analysis, we found out that the ones marked as 'Unresolved' were the tests imported with Test Case Importer, that were imported already in the workflow status that is set as 'resolved'.

The manually created test issues, since they go through the several status in the workflow, when they are set into the 'resolved' state, the Resoltuion is the expected one DONE.

Any idea on why or how to solve this situation?

[Nic Brough -Adaptavist- · Accepted solution]

Welcome to the community!

"Unresolved" in the resolution field is usually not actually a value.  It is Jira finding the field empty and displaying "unresolved" to the humans, because that's what an empty resolution means - the issue is not resolved.  Any value in the field means "issue is resolved".  (Even if an inexperienced Admin adds "unresolved" to the list of options, that still means the issue is resolved, because it's not empty)

So, my guess would be that your test cases did not have resolutions to import, and they've come in blank, hence displaying "unresolved"

Resolution should be set in the workflow - cleared out with a post-function in transitions that are re-opening issues, and set by either a post-function or with a resolution field put on a screen during a "close" type transition.

To fix the test cases that have come in with no resolution, the off-the-shelf thing to do is to transition them through the workflow to an end state, assuming it has one of the two ways to set resolution when closing them.

You could also re-import, using the issue key of the test issues and a resolution column as the imported data

Or you could bulk-edit the issues - however, this is slightly risky - you have to temporarily add the resolution to the "edit" screen for the issues, search for them, select the ones to update and then set a resolution.  When complete, you must remove the resolution field from edit.  The risk here is that someone edits another issue that uses the same edit screen while the resolution is on it - they will inadvertently resolve any issue because the resolution field is on the edit screen. 

[Cláudia Dias]

Thank you so much for your answer and how to solve the situation :)

But here you state:

"To fix the test cases that have come in with no resolution, the off-the-shelf thing to do is to transition them through the workflow to an end state (...)"

I put this question here exactly because the case is that the test case imported is in an end state of the workflow.

For example, my end state in the workflow - which is set in the workflow as resolved - is 'In Use'. I create a test issue manually, transition it through the workflow to the end state 'In Use', the Resolution becomes 'Done'. I now import a test issue, which in the csv to import I define that the issue will be created already in the workflow status 'In Use' (end state). The issue is displayed in Jira as 'unresolved'.

Why doesn't Jira recognize that the imported test issue is in an end state of the workflow and sets the correct/expected resolution?

[Nic Brough -Adaptavist-]

Workflows are made up of two things - steps (each of which has a single unique status mapped to it) and transitions.  An issue is created at one step in the workflow and to change steps/status, you move it through transitions.

A step is a state of being, whereas a transition is an action (that changes the state of being).  Resolution is a field, simply holding data.

Resolution is an unusual field in that it is not usually edited directly, it is set by transitions, not entered by people (ok, they get to choose one in resolution screens, but that's still part of a transition)

The important thing here is that status and resolution are not only totally different things, they have no relationship.  Technically.  Logically, of course they do, and it's something we always talk to new admins about so they know that part of their job is to define that relationship correctly.  But there is no coded link.

In every Jira system on the planet, you could tell me what a status is (translating it into English so i know what it means) and I would not be able to tell you whether the issue is resolved or not.  If it should be, yes, most of the time, but because resolution and status have no coded relationship, there is no way I could tell you whether the resolution is filled or not.  And vice-versa - given a resolution, and even a list of status available in your system, I have no information on what the status of an issue is.

When you import issues, you can tell Jira what status they should be imported in, but they go through no transitions to get there, so even if you've built your workflow to handle resolutions correctly, Jira has no way to know that they should be resolved.

[Cláudia Dias]

Nic, thank you so much for the explanation. We had thought of that possibility - if there is no transition how can Jira know it should be resolved - but maybe there could be another explanation or cause. I will pass the information in your answer throughout our organization.

Thank you once again. :)