Bug is a common factor between a tester and a developer. A developer creates a bug, tester identifies it, and then the same or different developer in turn kills the bug. A developer has two faces – creator of bug and destroyer of bug.
The intermediate phase is identification of bug which is performed by the tester.
It may happen and it mostly happens that new bugs are generated while fixing the old ones. And that makes this cycle repeatable till all the bugs are reported closed by the testing team or if in between development team decides to withdraw further testing. The second option is quite dangerous as the bugs suppressed will definitely play their crashing role at later stages.
It is always better to connect a bug to its creator, killer and identifier for the following reasons:
Billing: If the billing structure is such that the actual hours spent on the project are directly billed to the customer on weekly/ monthly basis, the time spent on bug identification, creation and closing are important for that purpose.
Time Sheet: The daily time sheet is required to be maintained by software organizations so that they come to know where the employees are spending their productive time.
Project Cost: These costs definitely add up in the ongoing cost of the project. to estimate the cost incurred at any stage of the project, these costs need to be accumulated in the total cost of the project.
Project Delay: Definitely if the bugs closing and testing cycle is repeated many times to bring the product to the expected level of performance, the delay in timelines will count in such exercises.
Performance factor: To evaluate an individual developer or tester at the end of a project, during a project or at the time of appraisal, this data will help in assessment. The developer generating more bugs, the tester coming out with less bugs, the developers taking more time for bug fixing etc. will help in the proper evaluation.