Help - Workflow with QA

Question

Hello,

Some few months ago I started working with Jira and adopted Jira Software for our scrum sprints. But studying and learning better how Jira's workflow is flexibile, I noticed the need to change the way our team is working to include QA in our workflow.

I know how to create new workflows in Jira and how to work with workflow schemes, etc. What I am missing is a "proper" way to use Jira for workflows that has QAs status.

I know this is a subjective question, but do you guys with more experience using Jira and with product teams recommend a particular way to work with QA and Jira workflows?

For example, if an issue transitions to "ready for QA" status, should I change the assignee? Changing the assignee can mess up reports: the issue was done by who? If changing the assignee is not the correct way to do, how QA team will know there's a new issue for them to work on? And how they will know who from QA team should work on which issue?

Are there good examples of workflows best practice for QAs?

I am kind of lost with these questions. I know there is not a "correct" way to do these things, but maybe I could learn with you guys, that has much more experience than me.

I welcome and appreciate your help and comments :)

Gui.

John Funk · Accepted Answer

Hi Gui,

We use Kanban and a Pull system to communicate the work and move it through the workflow.

If you are not using a pull system, you have to in some way not that the work is ready for QA. So if you want to include a status of Ready for QA, then that is fine.  And then have an actual QA (we Test) status.

We also have each transition assign the issue to the person who moved the card. So if you put the card into Ready for QA status, then your name would be on it. But QA would know that it is ready to work on because of the status/column the card is in.

When the QA Analyst pulls the card to QA to start working on it, it will assign it to him/her.

tokcum · Accepted Answer

Hi Gui,

in addition to what John proposed I would also define a role for QA team and include a condition on the transitions to make sure that only QA team is pulling issues to QA. You also might think about some level of protection to issues in QA to restrict changes. This could be done via properties defined in the corresponding states.

You should also rethink what happens to issues which do not pass QA. I know, in an ideal world, this doesn't happen. But from my experiences with workflows in different environments it better to prepare the workflows also for the exceptions to the rule.

Kind regards,

Tobias