A debate about the state of the defect

In our defect library, there is a defect status of "to be submitted", which is a final state, and indicates that the defect is actually invalid and will not be included in the final defect report.

A project begins, and after several versions, there are several "to be submitted" defects in the defect library for several reasons: repetition with other defects, testers' errors, and so on.

Let's turn to the resulting argument: a colleague believes that defects in the "to be submitted" state should not exist in the defect library. Literally, "to be submitted" is the pre-state before submission, which is changed to a valid defect and reset to the "new" state. In this way, from the defect library point of view, it will not expose the tester's mistakes, and can give superiors or others the impression that the test is very efficient.

But I don't think so: whether it is repeated defects or testers' mistakes, this is a real reaction and record in the process of system testing, and it is inevitable. After the end of the testing activity, all defects in the "to be submitted" state can be uniformly analyzed to guide the subsequent testing activities. In other words, the defect in the "to be submitted" status is also a resource that can dig out useful information. If you make it disappear artificially, although on the surface it appears to be efficient, people who really understand the software testing process are bound to find something suspicious.

With regard to the outcome of the argument, I can only say that the other party is in charge of the project.