How to assign issue to QA resource without removing developer from assignee

Ryan Courtnage January 16, 2013

Hi,

I'd like to hear how people handle this scenario:

  • Issue assigned to Developer A
  • Developer A fixes and "delivers" the story
  • QA Person A picks up the issue to test it

Currently, we are have QA Person A assign the issue to themself, so that other QAs don't pick it up. However, I've finding this isn't the greatest when it comes to reporting. If I want to see all MY ISSUES, that have been accepted, I'm kinda stuck.

How is this supposed to work?

Thanks

2 answers

1 accepted

0 votes
Answer accepted
Bhushan Nagaraj
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 16, 2013

Hi rcourtna,

There are many more ways to do this. But if the current setup you have is working well for you, you can use this query to get all the issues that were assigned to you when it was in Open state:

status WAS IN ("OPEN") and assignee WAS ("yourname")

You can add the below line to the query above to get all the accepted ones:

and status is "Accepted"

Or you can add the below line to the query above to get all the delivered ones:

and status is "Delivered"

Renjith Pillai
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 16, 2013

I am thinking that you can keep the same workflow and just use this JQL

status = Accepted and assignee was yourname

https://confluence.atlassian.com/display/JIRA/Advanced+Searching#AdvancedSearching-Assignee

EDIT: Read Bhushan's comment properly after posting this answer. Changing it to comment.

Bhushan Nagaraj
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 16, 2013

Agree with Renjith. I feel your QA team should be responsible for looking at issues that have been Delivered and assign it to themselves. And if your current workflow is working well for you, there is no reason to change it. Just use the JQL.

Ryan Courtnage May 7, 2013

Thanks! What I ultimately wanted was to show all the stories currently assigned to a user OR those that were assigned to the user when the story was delivered to QA. Here's what ended up working great for us:

((status WAS IN ("Delivered") AND assignee WAS myusername) OR (assignee = myusername))

Or even better:

(assignee = myusername) OR (assignee IN membersOf("jira-qa") AND assignee changed FROM myusername TO membersOf("jira-qa"))

2 votes
Andrew Morin January 16, 2013

So a couple questions...?

1. Are you the developer who delivers the story so you no longer have the issue assigned to you?

2. OR are you on the QA side and is the ticket being reassigned after the testing is completed?

I am guessing you are on the developer side so I will come from that perspective and I think that you have a couple of options.

Option 1:

Use a custom workflow something like Open -> In Progress -> Ready for Test -> In Test (this would be the status that would replace the QA resource from assigning it to themselves.) -> etc... One of my teams actually preceeds the "Ready for Test" status with a two steps, Ready for Build -> Deployed to to Test so the they know it is in the test environment. The PM on the project does a bulk change on the tickets that made it in and were deployed.

Option 2:

Create a custom field, you may have to make it free form as I'm not sure if there is a good fit in the custom types that the testers can populate with their creds so the other testers know it was picked up.

I would actually combine the two so you can track both participants. I do agree it would be nice to either have multiple assignees or the option to add additional assignee fields. I think this could be helpful for many users though those of in development could have the developer, qa, and any other folks that play a role in the workflow. We have dev, qa, and marketing for our website involved in the JIRA workflow and I believe we leave them assigned to the developer throughout and use the workflow but we have a small team doing the testing...

Made this as a comment because it doesn't neccesarily answer your question but I think JIRA is flexable enough and you have some options...if there isn't a feature request for this there should be or one of you plugin developers could probably add this :-)

Suggest an answer

Log in or Sign up to answer