Mixed issues tracking

Question

I'm a software developer that receives bug reports from several QA teams. I have several issues with these defects main ones being:

• I receive identical defects from different teams, but because they are reproduced in different environments the QA teams don't (want to) consider them duplicates
• I receive multiple issues bundled in the same defect (issues that some times don't pertain to the same operating system for example), and the QA teams refuse to open multiple defects because "it would be hard to track".
• Most of the issues I get assigned aren't related to my code (which is kind of a front end) so I need to forward them to the appropriate team /team member (but since the issues are bundled together that's really confusing, or most of the time impossible)

I've tried to fix the QA team issues but I hit a wall. Does someone else have the same issue ? What would be a good strategy to handle this ?

Edit: To clarify, I'm not looking for a way to modify the QA team behavior, I'm looking for a workflow strategy to handle the situation.

Second edit: It seems that people insist on answering the wrong question. To be clear - I'm asking for a personal workflow strategy, I know what would be the be best approach in terms of the entire team, however pushing for that approach is not feasible.

Answer 1

If the QA team(s) are unwilling to permit consolidation of the tickets then the answer for the problems within your area would be to commit your changes on just one ticket and mark all of the relevant tickets ready for test referencing the commit, most trackers will allow this, and/or referencing the ticket that you committed your change on as a related ticket with the words - "Resolved as part of action on #nnnn" where nnnn is the ticket number.

For problems that are outside of your area of responsibility - I personally know that the front end always gets the blame initially - the best answer would be to raise your own ticket, consolidating the information, provided on the appropriate team, reference all of the existing tickets in the new one and mark the existing ones "Awaiting resolution of ticket #nnnn" with the number of the new ticket. When you get notification of the new ticket being ready to test/close you will need to mark the referenced tickets similarly, (if your ticket has an API you could probably automate this with a little python). Some people try to close the ticket based on it will be covered by but this will cause friction due to the fact that the originator of the ticket will still see the problem until the new ticket, which they may not have sight of, is closed.

Similar steps involving splitting a ticket out to multiple tickets - while a pain - would allow the work to be staged and allocated to different teams if necessary - the original ticket can reference all of the new tickets and can be closed when all the sub-tickets are closed.

While all of these steps involve some work on your part it should become almost automatic on your part - indeed some parts may be able to be automated - but will keep the various QAs in the loop, preserve tracability and should get you a good name with the other teams as they will be getting a single ticket from you rather than a flood.

It is also worth talking to the administrators of the ticketing & VCS systems to see if it is possible to reference multiple tickets within a commit directly, link ticket statuses - e.g. when this ticket changes state update these tickets to the same state and this ticket can only be marked as closed by the closure of all of these.

Answer 2

Ya know, it's late at night for me but it sounds like you are getting too many tasks assigned to you.. I would

1. Prioritize the QA tasks. There should be less than about six tasks at any time that are high priority...something like that. Do the lowest priority tasks really need to be completed?

2. Revise prioritizes and estimates regularly. If too many new QA tasks are coming in, seriously consider removing the lowest priority ones or defer them to some other time.

3. Applying Agile programming practices. Involve the QA manager and stakeholders in a calendar of releases or sprints spaced as regular units of time (daily, weekly, bi-weekly, monthly, etc. etc.) Let QA management know what tasks can reasonably be completed in each unit of time.

Hold daily scrums.

And I've been drinking hot toddies, but all and all, set boundaries and use stakeholders to hold QA accountable to consise bug reporting. I use to work in QA and often felt empathy for dev. Much love!

Answer 3

This is all about process, organization, workflow and communication. Take a step back and think about the big picture and how things should work. First work on the big picture with everyone and then drill down to the details, making an extra effort to map out the workflow, agree on the details and iron out the kinks.

I would focus on:

• promote the whole team approach site with physical co-location whenever possible.
• agreeing on whether folks should search for existing issues first.
• discussing and agreeing on the criteria to use to determine when a ticket is really new or just another instance in another environment. You can use some past examples to help drive the conversation.
• talk about the advantages and disadvantages of tracking multiple defects and find out what the specific issues are that this presents to the QA team
• talk about how having multiple issues or both front and back end issues is or isn't working for you - and the QA team - and how you can reach compromises on what will work ok for both. Maybe not perfect for both - teamwork requires that.
• have scheduled retrospectives that re-examine the process and see what is working and what needs to be changed.

btw "I'm not looking for a way to modify behavior". hmm. It's ok to. For both Developers and QA team. It's Agile, it's a good thing. It's part of change and learning. Behavior is part of the big picture workflow.