When a bug is first logged, it is given Unconfirmed status.Since the software bug is logged, some things may happen to it:
- The organization may be such that the tester entering the bug directly assigns it to the developer or answerable for this specification writers.
- Another possible situation is that a manager or group of managers may comb through all the bugs and assign the significant ones to the developers to be fixed.
Life cycle of a bug
You may think that the first method is faster, but the second method guarantees that any duplicates, bad bugs, or tester fouls get weeded out.
Software bug ultimately makes it to a developer, who then estimates it. The bug may require a simple change or may entail a total feature request. The developer finishes checking the code changes into the main tree, which is what the builds are produced from.
Since that code is checked in, software bug always has its status changed so that it is active no long, and it is assigned back to software tester to verify.
Since a build is generated that contains the fix, you become answerable for verifying if the changes fixed the issue, caused a regression, or did not address parts of the trouble.
If the issue has not been resolved, the bug will be reactivated, and the cycle will start from the beginning.
Sometimes, the fix unblocks new code ways, where new software bugs are found. In that case, it is always better to open a new database entry for the new bugs and mention, when you log the new bug, that the fix to the old bug unblocked it. This new bug then goes through the cycle. If all goes absolutely, the life cycle of a software bug looks like on the picture.