Bug life cycle is the process in which bug move from one state to another state until it is fixed or closed. There are some states defined for bug during their life.
The status field indicates the current condition of a bug.
This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED.
This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED.
A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and become REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED.
QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken.
When any bus
The bug is considered dead, the resolution is correct. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED.
A fix for this bug is checked by QA and tested.
This bug has recently been added to the project. There are so many conditions when bugs are goes to invalid condition. When bugs are not requirement or scope and problem described is not a bug.
The problem described is a bug which will never be fixed. And this bus is not in currently working cycle. User can mark this bus as wontfix.
When user put same bugs more than one time with same objective and description under one project. The second bugs are duplicate bugs.