Suppose there are 3 module and all 3 are dependent on each.
3 testers are testing these module.in some cases there can a
situation that 2 testers are testing the same thing at a time and if they find bug and log that into bug tracker tool.
How we can remove this duplicity of testing and bugs.
Is there any method or tool to remove these.
The other end of this is where you seem to be focussed. I assume you have a central monitoring point for defects as they are raised? This is so taht they may be reviewed and assigned to the relevant person\team.
Where a duplication like this is discovered, ONE method is to make the bug assigned to the team that will do the change the parent bug and then close any others that duplicate it with the close reason stating that it is being closed as a duplaicte of bug number XXXX.
That way, the tracability will stay in place and so will the path for restesting.
"Not every solution was derived to address an obvious problem" - Me (quite recently indeed)
If you have a bug tracker that supports it, I'd suggest allowing a bug status of "Duplicate" which differs from "Closed," so that duplicate bugs can be excluded from total defect counts but kept in when reporting on number of bugs discovered by individuals.
Some bug management systems contain a feature which will flag potential duplicates. In our organization, it is the responsibility of the test coordinator to read bugs reported daily and to close duplicates. If the coordinator misses a duplicate, this is also done during our daily triage meetings.
for every test case we will be writing bug report, there is a POC(POINT OF CONTACT) who collects the test cases & bug reports and verifies them and if any duplication they are eliminated. Certainly this process can vary in different shops.
Duplication of tests through review of testcases.
Duplication of bugs, make sure the testers are aware of the current bugs or let them check the current bugs before the write a new one. This means you need to have an easy system to look for bugs. Bugs should have a decent description and if possible already assigned to the proper module.
In the past I've always subscribed to bug mailings list of the specific project. Based on the titles I saw in my mailing box I had more or less an idea what bugs were present.
In my organization each module is assigned a coordinator who would be responsible for reviewing defects and resolving duplicates in concert with the testing lead. For example, we might have an application with 3 modules- Security, Reporting and GUI. Each module is assigned a module coordinator (MC). If the Security MC finds a defect in the GUI module he would first check the defect tracking tool, Quality Center here, for a similar defect. If an existing defect is found he would simply attach a comment and describe where he found the similar defect. If no similar defect is found he would enter a defect and assign it to the GUI MC who would review it again and then assign to the developing organization. The Security MC can always go and discuss the defect with the GUI MC if there is any doubt about duplicity or validity.