In practice most often uses the following status of bugs:
Unconfirmed – bug just opened and had not yet been processed. When the tester opens bug, the first information about it gets one by default (for different test systems, it can be different people), reads it and forwards it bug the programmer, who will direct him to correct.
Bug goes into Assigned. As you work, the programmer can forward the bug to another programmer, who, for example, knows this part of the system better. Unfortunately, this creates a situation where a bug "stray" from one developer to another few months.
Assigned – Concrete Software has received this bug and now has to answer "for the market" – or someone else to fix their mistake.
If the error is not a "mistake" (tester was mistaken), then the bug becomes a Resolved-Invalid and forwarded back to the tester.
If your bug is about the same problem already, and working on that, then the bug becomes a Resolved-Duplication. For example, the error has been described previously and has been corrected, but corrected code has not yet acted to testers.
When a programmer error corrected, then the bug becomes a Resolved-Fixed. Programmer himself and puts these states.
Resolved (Fixed, Invalid, Duplication) – bug fixes and returned to the tester.
If your bug is able to Resolved-Invalid then the tester must once again make sure the error was or not. In other words peretestirovat.
When a bug in a position to Resolved-Duplication then the tester should verify that indeed, the other (s), similar (s) bug (s) exists, the number usually indicates programmer in his commentary. Trust, but verify.
When the Resolve-Fixed a bug tester checks (test problem) again. If the bug is fixed – Verified (Closed). If the error is not corrected – bug re-opened again (Unconfirmed, Assigned)
Verified bug fixes and peretestirovana on the test machine.
Closed – the error is corrected, and corrected peretestirovana code is placed on the live system, or a new build is released.