How to handle the situation where communicated bugs by the qa are duplicated as new issues by members of the project other than qa? What is the role if qa in this situation? Additional note: Time is limited, bug triage is impossible.
3
-
Why is triage 'impossible'?– Phil KirkhamCommented Mar 31, 2014 at 16:39
-
1You are right. It is improbable, given the small time frame between testing and release. You bave pointed your finger to the more elaborative question that says: can triage be eliminated in the situation where multiple people report issues otherwise logged by the qa personnel?The answers all stress on the importance of triage in centralizing the communication in addition to eliminating work redundancy and time loss.– user5529Commented Mar 31, 2014 at 17:04
-
2@user5529 At the point you start asking the question about eliminating triage it becomes a people/trust problem. Either you trust the people entering defects to keep their duplicates down, and enter useful defects that provide clear communication on what the issue is. Or you don't. Triage is not only a centralization process but a review process, because it tends to also dictate priority on a higher level of oversight than those entering the defects have– MichaelFCommented Mar 31, 2014 at 18:39
Add a comment
|
3 Answers
Without being flippant, this sounds like you've got a serious communication problem in the team.
Given the limited timeframe, here's a few things to consider:
- everyone in the team needs to know what a good bug report looks like
- everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means that bug report descriptions need to give a clear idea of the problem: I typically format my titles this way:
ModuleName:SubModule/PageName - ActionDescription produces ErrorDescription
- the bug reporting tool must have a good search function.
- anyone who finds a duplicate should link that duplicate to the original issue and close the duplicate.
If you can get everyone on the team doing this, it will help to reduce the number of duplicates created, and help to clear the number of duplicates active in the system without someone having to take the time for triage.
That said, despite the time constraints it's still important for someone to be performing bug triage to prevent time being lost. There's a saying in software that applies to your situation: "If you don't have time to do it right, you will have time to do it over." Not taking the time for bug triage guarantees that you'll be taking that much time or more doing the same things over and over for all the duplicate issues.
answered Mar 31, 2014 at 11:47
-
2"the bug reporting tool must have a good search function" - I find this is WAY more important once you actually have a fairly large repository of defects, since people do not like to search through long lists or even non-descriptive names. Getting people used to entering good descriptive titles, or triaging them over time, is useful in mediating this though it never quite gets rid of it when someone is just too rushed to do a good search or doesn't care to do so– MichaelFCommented Mar 31, 2014 at 14:25
When you say that bug triage is impossible (or improbable), you need to determine the opportunity costs associated with that:
In the case where no triage is performed, there is the probability that a single or multiple developers will attempt to fix the same bug. At minimum, there is wasted development time that could be focused on other areas. Worse, the developers could check in fixes at different locations in the code that end up counteracting each other, resulting in more lost time.
In the case where a tester performs a triage in the background, they may identify bugs that are duplicated and can avoid the worst case disaster above. The loss is some areas of the application may get less testing.
Another case is a tester dedicated to reviewing bugs before they are submitted to the developers. That sound like a bottleneck, but can occur very quickly if you have an experienced tester performing it. That person has to have a good understanding of the application(s) and the testing experience to understand severity and impact evaluation.
There are always alternatives, it is just a matter of balancing the costs for your team.
-
Thank you for the answer. It is interesting to analyse the risks of escaping from bug triage for the supposed aim of decreading time loss. In my question, when there is no centralized communication between qa, developer , project manager, how can you implement the tester's approach of triaging bugs before or after they are handed to developers? Can this be solved in a procedural manner or is it a miscommunication issue?– user5529Commented Mar 31, 2014 at 17:59
-
2Procedures are simply agreements between members of a team. If you are not acting as a team (no communication), then procedures can't help. The only way this will work is if all of the members of the team are convinced that sending potential bugs to the testers for verification is faster than sending them to the developers to fix immediately. That requires trust and communication. Without that, you will have to ask what is the actual role of the testers in the organization? I feel for you - I've been on projects like that in the past and it wasn't pretty. Good luck! Commented Mar 31, 2014 at 18:14
Bug triage is very important, especially when time is limited. Bugs have different levels of severity. Examples include very high: someone may die as a result; high: the company may lose business; medium: the customer will be upset; low: there is a minor spelling mistake. The actual outcomes and severities depend upon the organisation. Bug triage is about assessing bug severity and its impact on the project and the business; deciding which bugs need fixing soon and which can be delayed. Bug triage is about focussing your scarce bug fixing resources on the important bugs.
Kate's suggestion that "everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report" is very good but some teams may feel that that will take up too much time for the team members. Perhaps it would be better for the team members to do a quick check and, if no similar bug found, report the bug. Then rely on bug triage to detect duplicates.
answered Mar 31, 2014 at 12:31
