How should the assignee and reporter be set in Jira tickets for bug fixes?

[jiw]

Hello.

Our company uses Jira in the following scenario.

Let's assume a QA team discovers a bug in a system. The QA team creates a Jira issue ticket for this bug, where they are set as the reporter and the development team as the assignee. After the development team completes the necessary code fix, the assignee is changed to the QA team. The QA team then verifies that the bug is resolved and closes the Jira ticket.

In the end, both the assignee and reporter fields show the QA team, which makes it look as if the QA team directly fixed the bug.

Is this a good workflow?

How do you manage collaboration between QA and development teams in Jira?

Thank you!

[John Funk · Accepted solution]

Hi Jiw - Welcome to the Atlassian Community!

No, I would not assume that the ultimate assignee is the person who fixed the bug. This is just following the normal flow as it should. I think it is great as you have it. 

[jiw]

Thank you comment. Could you explain in more detail why you consider this a normal flow?

[John Funk]

The assignee is the person who is performing that step of the work. A task/issue will go through potentially several steps on it's way to Done. So different people will perform different steps at different times. That person is the assignee for that work in that step. If the last step is for QA to test and deploy, then the QA Analyst would be the last assignee, not the developer or anyone else. 

[YY Brother · Accepted solution]

Hi @jiw 

In my actual practices, the final assingee should be assigned back to the developer who submitted for testing. I will make statistics the total number of bugs of every developer based on the assignee field after the bugs are resolved.

Hope it helps,

Thanks,

YY Bro

[jiw]

I agree with your comment. However, from the QA team’s perspective, there is one issue to address. The QA team argues that they should be set as “Assignee” field because they are involved in the final stages of development. They also believe that the “Assignee” field should reflect the QA team for better tracking of their Jira ticket lists. Personally, I think having the QA team listed as the “Reporter” should be sufficient. How do you think?

[John Funk]

I would 100% disagree with this approach. If you need to run reports about who the developer was, then create a custom user picker field to capture the Developer and run your reports from that. But in no way is the assignee at the end of the process to be considered to be the developer who worked on the issue. 

[jiw]

@John Funk 

Thank you for sharing such a great idea! I learned a lot.
I think creating a custom field called 'Developer' would be a good idea.
Lastly, could you provide your opinion on my question?
I think that the 'Reporter' can provide feedback on the 'Assignee's' work results. In this sense, does it really make sense for the QA team to be set as the 'Assignee'?

In our company, all Jira tickets have the same 'Reporter' and 'Assignee.'
In the end, all closed tickets are as follows..
- For bug tickets, the 'Reporter' is the QA team, and the 'Assignee' is also the QA team.
- For new feature development tickets, the 'Reporter' is the Planning team, and the 'Assignee' is also the Planning team.
I think this is unusual.

what do you think?

[John Funk]

No, Assignee should be a single person, not a team. It is the person doing the actual work. The whole team is not doing QA on that single issue - only one person is. So that should be the person in the Assignee field. 

What is it that you are actually trying to accomplish? 

[YY Brother]

Less is more. I think taking the ultimate assingee as the developer who fixes the bug can replace creating a new custom field, a simpler solution. 😊

The person who creating bugs is the reporter, which does make sense. That is, QA is the reporter of bugs. 😊

[jiw]

@John Funk  I apologize for any misunderstanding. When I referred to "reporter" and "assignee," I was talking about individuals, not teams. I realize now that my wording caused confusion, as my use of "team" was meant to indicate individuals, not a group.

Here’s the situation I wanted to clarify. We have a bug ticket where "QA Staff A" is the "reporter," and the "assignee" is initially set to "Developer Staff B." Developer B fixes the issue, then reassigns the "assignee" field back to QA Staff A, who verifies the change and closes the ticket. As I mentioned earlier, this is our company process in Jira: the "assignee" field changes from QA A -> Developer B -> QA A.

As a result, for bug-type tickets, the "reporter" and "assignee" often end up being the same person. I find this approach somewhat unusual—if the "reporter" and "assignee" are always the same, it raises the question of why Jira separates these fields in searches. This is why our process feels a bit odd to me, and I wanted to get your perspective on it. You mentioned that QA is part of the development process, so it makes sense for QA to be listed as the "assignee" in such cases. In your experience, have you encountered a similar setup that felt awkward like this?

How about changing our company’s Jira process as follows?. QA A could initially report the issue and assign Developer B as the "assignee." Developer B would resolve the issue and reassign the "assignee" field back to QA A for verification. After QA A confirms the fix and closes the ticket, they could reassign the "assignee" back to Developer B. This way, QA A remains the "reporter," and Developer B stays the "assignee," which resolves the part I found awkward. It becomes clear that QA A found the bug issue, and Developer B fixed it. What do you think of this approach?

[John Funk]

Thanks for the clarification. You can do that if you like. I still do not know what you are trying to accomplish. Do I agree with the reassigning the Assignee back to the Developer when it is already done? No - he was not the assignee of the last function performed on the task. Of course, I also don't like the idea of QA assigning the task to a developer unless there is only one developer on the team. That's not a very agile way to work. 

[jiw]

@John Funk I apologize if my explanation is unclear due to my limited English skills. I’m Korean and using AI assistance to write this comment. My thoughts align with those of @YY Brother 

Here’s my perspective: typically, bug fixes are handled by development team members who correct issues in the system, rather than by QA staff. I find it odd that QA team members are set in the 'Assignee' field of a Jira ticket to provide feedback (or to verify the bug) and then set the Jira ticket to closed status. In the end, when the Jira ticket is closed, both the 'Reporter' and 'Assignee' fields are QA staff. This makes it appear as though the QA team fixed the bug by modifying the system’s source code themselves.

Let me provide another example. A QA member might create a Jira ticket after discovering a bug, and in some cases, the QA member can resolve the issue independently without involving a developer. This typically happens when the issue was a temporary one caused by a QA error or a network problem within the system. In this situation, the QA member naturally closes the Jira ticket themselves, and having the same person in both the 'Reporter' and 'Assignee' fields makes sense.

At our company, however, we are required to set the 'Reporter' and 'Assignee' fields to be the same, regardless of the situation. This is done so that, at the final stage, the 'Reporter' becomes the 'Assignee' to provide feedback on the Jira ticket resolution to ensure the problem has been addressed. Consequently, when the ticket is resolved and reaches closed status, the 'Reporter' and 'Assignee' fields are always the same. But why must the 'Reporter' become the 'Assignee' to give feedback? Doesn’t the 'Reporter' inherently have the right to provide feedback? This approach feels odd and counterintuitive to me, which is why I posted this question here in the Jira community.

[John Funk]

There is no apology necessary, and the English is very good. I just don't agree with what you are saying, though I understand it completely.  :-)  Same goes for @YY Brother - not in agreement with his either.  :-)

But you can work however you like and however your company has decided you have to do something. 

And I disagree that just because the QA Analyst is the last assignee that it implies that they made the but fix. That is nowhere implied in Jira or anywhere in Agile that I am aware of. 

And I am not aware of the Reporter having to be the Assignee to provide feedback. If your permission scheme is set up that way, then you can change it.  

[jiw]

@John Funk , Yes, It’s good to know I’m not the only one who felt that way about the thought. Your feedback has been very helpful in organizing my thoughts. The idea about the 'custom field' was impressive and made me realize the need to study Agile. From our chat here, I plan to discuss our JIRA practices at my company. thank you

[John Funk]

You are welcome. Best of luck to you!