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.
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.
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.
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.