Best Practice: Resolution after user testing or after developer fixed code?

[Dori Semenov]

I am planning our implementation in Jira and currently designing a bug workflow. I have Administered Jira before in a previous life but am a little rusty on details. What is an optimal approach with respect to filling in the resolution field (given its special nature in the Jira UI) - should it be filled in by the developer after a code fix and on its way to the UAT environment or should it be set when the user passes the bug in UAT and we know its good to go for the release to production?

[Anthony Pelosi · Accepted solution]

Reference: Practical JIRA Administration By Matthew B. Doar

http://books.google.com/books?id=FofOMyfNQf0C&lpg=PA21&ots=aY3hjdpA9F&dq=common%20practice%20for%20default%20jira%20workflow&pg=PA7#v=onepage&q&f=false

Page 7-8:

The idea is that an issue (such as a bug) is created with a Status of Open, and is then moved to In Progress and then Resolved by the person who fixes it. The bug is then moved to either Closed or Reopened by someone who checks whether it really was fixed or not. So "Resolved" is just a name for an issue status. The status could just as well have been named "Believed Fixed" or "Ready for Testing".

Page 8:

Jira expects the Resolution field to be set in any status you would consider an issue resolved."

So if the developers click Resolve and is presented with the option to set the Resolution field, they should set the Resolution field as well. I agree with Matt, the developer should mark the issue as resolved after they test locally and commit the changes to source control, and so they should set the Resolution field as well in the transition screen after they press Resolve. The Resolution field gets cleared if re-opened, so not sure why you wouldn't want the developer to set that field when resolving for the tester's own knowledge on how the issue was resolved.

[Joe Pitt]

The problem with setting the resolution field anytime before the issue is closed is it will more often than not in my experience be ignored from then on. It will no longer appear in most of the standard views such as assigned to me. We ended up creating a field called developer resolution for bugs and the developer would set that and move it on to testing. The resolution field was presented when the issue was closed.

[Anthony Pelosi]

Quoting myself here: "So if the developers click Resolve and is presented with the option to set the Resolution field, they should set the Resolution field as well."

Sorry, I couldn't quite remember the default workflows since we've modified ours quite a bit, but if the Developer is NOT presented with the option to set the Resolution Field when resolving then they don't really have a choice. In our instance, it automatically sets the Resolution Field to Fixed when the developer clicks Resolve, and therefore they are the ones indirectly setting the Resolution Field. Pretty sure the only time an individual is presented with the Resolution Field is when they close an issue from another status than resolved (such as Open), but I'd need to go back and double check with the default workflow...

[Pedro Cora]

IMHO, the resolution should be set after passing thru the tester / test sessions. This way, you avoid having to clear the resolution if the code is not approved in such steps. ;)