How to reflect completed Development work in a shared board with QA

[Tom Garland]

Hi. I'm looking for some advice on an approach to take with a particular issue we are having:

We have a combined development and qa board. Our workflow is as follows:

Todo->In Progress->Review->Ready to test ->In Test-> Done

The current process is as follows:

When the dev team complete the coding and review of a feature or bug fix they let the QA team know that it is ready to test by moving the corresponding jira issue into "Ready To Test". This lets the qa team know that a build is available with the feature or fix in it. We want the qa team to test and verify the feature /fix before the issue is marked "Done".

This results in the following problem:

The dev team want to be able to show their progress to management (through jira native reporting). However, even though they have completed the development work, our process requires that the corresponding issue cannot be marked as "Done" until the qa team have tested and verified the feature/fix. So, all of the dev issues sit in "Ready To Test" or "In Test" until that happens and the dev team doesn't get any kudos from the jira reports for having completed their work. Questions get asked by management who are looking at the jira reports as to why the dev work has not been done yet when it actually has been done.

The following is our proposed solution for this. Would value your input or any alternative suggestions:

Proposal:

1. After review has been completed by development (includes unit testing) the dev team adds a label to the issue (e.g. "qa_ready") indicating that the feature/fix has been completed and is now ready for testing
2. Dev team marks their issue as "Done".  -------> This gets them the kudos
3. QA runs a daily filter to search for dev team issues with label "qa_ready"
4. On finding an issue with this label the qa team creates a separate qa issue which links back to the original dev issue through the jira "tests" link
5. QA team changes the label in the original dev issue from "qa_ready" to "qa_received" a) to allow for filtering and b) to indicate that this story has already been received by qa
6. The qa story moves this new qa issue through the above workflow

Note that we as a team have discussed the approach of having a single issue owned by either dev or qa at any given time thus avoiding the need for separate dev and qa issues but the consensus was that this would make it difficult to provide separate dev and qa progress reports in jira which is what our management team wish to see.

I would be grateful for input as to whether we are on the right track here or completely off.

Thank You

[Dick · Accepted solution]

Hi @Tom Garland 
Thank you for this well-described question. You're right in choosing two individual Jira projects that individually can be monitored for output. 

Key in your approach is thus: how do we produce the corresponding QA ticket in the QA project?  This is where Automation is your friend. You can:

• Have an automation trigger: when a dev-ticket gets the status Done
• Do the action: create a ticket in the QA-project and copy some of the necessary fields (or all) from the Dev-ticket into the newly created QA-ticket. You can even link the two together using the linked issue system field.
• Have the QA team do their testing. On failure someone from within the Dev-team (team lead?) should be contacted to either re-open the original ticket or create a new ticket with additional information about the test results and the link to the original dev-ticket.

So you're on the right track here. An automation can help you get the QA ticket

Kind regards,

Dick

[Tom Garland]

Thanks @Dick 

Thanks for getting back. We are not actually using two separate jira projects. This is a single project with a combined board for both dev and qa. The automation trigger suggestion for automated the creation of the qa ticket looks interesting. I iwll look into that

Many Thanks

[Dick]

Hi Tom,

As reporting is required for both Dev and QA team, you should give them each a project to work in. It is a prerequisite for Jira to provide metrics of both teams.

An overview of tickets from both projects can always be generated using a board that filters in the issues of both projects, so that's not a reason to keep these teams in one project. 

The automation described above can generate the necessary follow-up QA tickets (in the QA project) after the Dev-team has concluded work on a ticket and have set it to "Done". 

Kind regards,

Dick

[Tom Garland]

Thanks Dick.

I understand your logic in suggesting two separate projects but I'm loathe to go the separate project route as,philosophically, we see this as a single project with two different functions (dev and qe). Also, the single project approach and native jira reports that we can generate work well for us with the exception of this wrinkle.

Tom

[Dick]

Wrinkles are what makes us human. 

;)

Dick