I've been working on a distributed team for over 8 years, and gradually moved to architect of the product I work on.
There's a lot of good advice in this thread, but one more thing that I need to add:
Your tickets need to be well-written, and actively groomed. This means things like:
- Clear ticket title
- Clear steps to reproduce
- Process followed (Varies based on product, in our case this means attaching logs and documenting filenames.)
- When someone clarifies things, they must update the actual ticket title / description instead of clarifying in an email / comment
- Management must not expect engineers to handhold ticket writers through things like this, and must expect that testers and support own clearly communicating what the issue is
- Do not combine multiple bugs into the same ticket
- Do not "fail verification" when finding a new bug
- Relate similar tickets, don't identify new bugs / issues in a comment
Some examples of "bad" tickets:
- Giving a title that's basically "It's not working." Every product has an analogy of "It's not working." In our case, novices who don't take the time to explain a problem will just create a lot of tickets titled "It's not syncing."
- I had a ticket today where the steps to reproduce said, "Take a screenshot." There's MANY ways to take a screenshot. The steps to reproduce must say which tool / button combination were used.
- Constantly needing to ask for things that are expected in the process. All products have different needs. In our case, all tickets need logs and a sample filename to look for in the log. When I need to constantly ask testers for this information, it's a problem that management must address quickly
- "Oh you fixed it but now it does this." What this creates is a situation where many bugs are part of the same ticket, and someone needs to spend hours reading through all comments to understand what the bug is. If the bug is fixed and a new bug is found, verify the first bug, file a new ticket, and relate them.
Edit: Actively grooming means:
- The bugs assigned to someone must be realistic. Don't leave 100 bugs assigned to someone for a release when there's no chance that they can do them all.
- Don't let your ticket submitters triage their tickets. QE shouldn't assign a ticket to anyone. That just results in the 100 bugs assigned to someone situation.
- Dumb feature requests should be closed immediately. Someone using your ticketing system to make dumb feature requests (and assign them to people) should be stopped immediately. (An example is a tester requesting lots of automation or helper tools from developers via the ticketing system.)
- Out-of-scope bugs should not be assigned to a release
- Major projects are not bugs, don't leave "bugs" that require major refactoring assigned to someone when you aren't going to dedicate the time to do it
- Establish a feedback loop so that QE can better steer tickets on submitting them. (IE, if there is a clear server error in a log, it's not a client bug.) QE should be smart enough to do enough diagnostics to direct the bug before it hits triage.
- Don't constantly assign tickets to the wrong team. If someone keeps saying, "this kind of ticket goes to this team," listen, otherwise they will go to your upper management, CTO, architect, ect or and make you look like a fool for not knowing the difference.
There's a lot of good advice in this thread, but one more thing that I need to add:
Your tickets need to be well-written, and actively groomed. This means things like:
- Clear ticket title
- Clear steps to reproduce
- Process followed (Varies based on product, in our case this means attaching logs and documenting filenames.)
- When someone clarifies things, they must update the actual ticket title / description instead of clarifying in an email / comment
- Management must not expect engineers to handhold ticket writers through things like this, and must expect that testers and support own clearly communicating what the issue is
- Do not combine multiple bugs into the same ticket
- Do not "fail verification" when finding a new bug
- Relate similar tickets, don't identify new bugs / issues in a comment
Some examples of "bad" tickets:
- Giving a title that's basically "It's not working." Every product has an analogy of "It's not working." In our case, novices who don't take the time to explain a problem will just create a lot of tickets titled "It's not syncing."
- I had a ticket today where the steps to reproduce said, "Take a screenshot." There's MANY ways to take a screenshot. The steps to reproduce must say which tool / button combination were used.
- Constantly needing to ask for things that are expected in the process. All products have different needs. In our case, all tickets need logs and a sample filename to look for in the log. When I need to constantly ask testers for this information, it's a problem that management must address quickly
- "Oh you fixed it but now it does this." What this creates is a situation where many bugs are part of the same ticket, and someone needs to spend hours reading through all comments to understand what the bug is. If the bug is fixed and a new bug is found, verify the first bug, file a new ticket, and relate them.
Edit: Actively grooming means:
- The bugs assigned to someone must be realistic. Don't leave 100 bugs assigned to someone for a release when there's no chance that they can do them all.
- Don't let your ticket submitters triage their tickets. QE shouldn't assign a ticket to anyone. That just results in the 100 bugs assigned to someone situation.
- Dumb feature requests should be closed immediately. Someone using your ticketing system to make dumb feature requests (and assign them to people) should be stopped immediately. (An example is a tester requesting lots of automation or helper tools from developers via the ticketing system.)
- Out-of-scope bugs should not be assigned to a release
- Major projects are not bugs, don't leave "bugs" that require major refactoring assigned to someone when you aren't going to dedicate the time to do it
- Establish a feedback loop so that QE can better steer tickets on submitting them. (IE, if there is a clear server error in a log, it's not a client bug.) QE should be smart enough to do enough diagnostics to direct the bug before it hits triage.
- Don't constantly assign tickets to the wrong team. If someone keeps saying, "this kind of ticket goes to this team," listen, otherwise they will go to your upper management, CTO, architect, ect or and make you look like a fool for not knowing the difference.