Bug Management during testing

Testing is an essential stage in the software development process. Everyone's focus may be on how testers discover bugs and how developers solve bugs, rather than focusing on Bug Management. Here, I would like to introduce how to manage the bug process during development. More importantly, I would like to know how everyone is doing the relevant work and hope to have in-depth exchanges with you.

First of all, we need to introduce the Bug management tools. This should be shared by developers and testers, such as Bugzilla and bugfree. We have not used the Bug Management Tools separately, instead, TRAC is used to manage and control bugs with ticket. Ticket in TRAC has its own stateful workflow definition. We use version 0.11. The ticket status is as follows:

Then, I will introduce how to control the bug process:

After the developer code is complete, release a 0.1 software version for testing. The tester tests the version. Once the bug is detected, a new ticket is created in TRAC to describe the bug and specify which developer receives the ticket. It also specifies the software version of the bug.

After receiving an email notification from TRAC, developers can log on to Trac to view their own ticket list. If this ticket belongs to its own modification scope, it will be accept. If not, reassign will be given to other developers. The next step is to fix the bug. After the fix is complete, change the ticket status to resolve as "fixed ". If the bug does not need to be modified or is not a bug at all, you can select resolve as "wontfix" and resolve as "invalid ". After handling all bugs, developers can build a new software version 0.2.

The tester performs the second round of testing. First, they need to check all the ticket reported in the first round. If the developer fixes the bug, you can change the ticket status to "verifed". If you find that the ticket is not completely modified, and the developer marks it as fixed, the tester can perform a reopen operation on ticket. At the same time, change the specified software version of the ticket to 0.2. Then, continue the test and report a new bug.

This loop continues until the tester fails to detect the bug, or the fixing of the remaining bug is stopped. The tester submits the test report. The report includes the total number of bugs detected in each round of testing and the number of bugs that have been fixed.

The above is our current application testing and Bug management process. There are still some problems that plague us:

1,After the tester finds a bug, fill in ticket. Who will the tester first send?(Directly sent to the tester brings a lot of communication costs, for example, the tester thinks this is not a bug, etc.; or can the tester decide whether this is a bug, and the person who does not need to modify the bug, such as the project manager)

2. Does the bug itself have a version?(The bug is only for a certain version of the test software, or is it followed by the software version, such as the reopen bug)

3. Is there a better test management process, including Bug Management?(I hope to discuss this issue with you in depth and thoroughly understand it)