Why are closed / resolved linked in stone?

[s]

I asked a question here about how to model retesting in the system. The answer I got was that we need to alter the workflow. I've found out how to do that but I'm still confused about the link between resolution (resolved) and status (closed).

When a developer resolves an issue it closes it. That means that the issue is now closed and cannot be assigned to a tester to retest. Then we need to reopen it so we can reassign it for retesting.

I think what we need to know is why are closed / resolved linked? Why can't we just allow a developer (client company) to resolve an issue and if we (independent test team) agree it is resolved then we close it?

As a secondary issue, we need to record in JIRA that we've retested something. So we would need to record the 1st retesting, with a date and comment, then after another attempt to fix we would record the second retesting. How can we do this so we have a list of retestings?

My previous is here: https://answers.atlassian.com/questions/69967/jira-workflow-how-to-show-retesting-of-bugs

[Nic Brough -Adaptavist-]

Well, they're not actually set in stone, or even linked directly.

The behaviour of Resolution is pretty much fixed. If a resolution is set, it's resolved. If there's no resolution, it's unresolved.

Closed is a status that lives in the workflow.

There is a close logical relationship in the default workflow, which is to have TWO status where going into them sets a resolution, and going out of them (re open) blanks it out. But this is a purely logical relationship - you can easily define a workflow that doesn't do that at all. For example, in your case, it might make sense for you to have the "resolved" status NOT have a resolution, and only resolve issues when finally closing them. Another option might be to drop out the resolved status entirely. Or not have "closed" (e.g. our "test sub task" workflow here has "open", "passed" and "failed" - no resolved or closed at all)

For your re-testing issue, I'd use "reopened", or think about adding "needs retesting". At the very least, you can then use the history to start looking at "number of reopens" and when they're done. Going back to the really simple test workflow I mentioned above, it has reopen, and we have a counter showing number of re-opens