As a first step to tackle any confusion regarding the terminologies used by a team, I would talk to the team members. They are in the best position to give you an answer and it will also help to start a conversation and be more comfortable with them.
–
Suchit ParikhNov 14 '12 at 18:12

@Suchit, the problem is the tester(this project needs only a single resource) who used to maintain the defect sheet and also was responsible for testing is now moved out and now i have been given charge of the project.
–
GarvNov 14 '12 at 18:18

BTW, have you tried to describe bug lifecycle with state transition diagram? Here's one for Bugzilla? It is a bit clearer to read.
–
dzieciouNov 15 '12 at 7:51

Thanks to all for your valuable answers and comments.
–
GarvNov 16 '12 at 5:49

6 Answers
6

You've got a pretty good grasp of the defect life cycle, however the terminology and even the flow can change from project to project and team to team. Most likely, "Open" is the same as "New". More important than what term to use is ensuring that the team are all using the same terms.

(Some shops mark a defect as Open and only mark it as In Progress, once it is assigned to a developer, or once the developer actually starts working on it. Other shops leave bugs as Open, rather than In Progress, until it is fixed.)

Terminology is, as you say, key. I'd use Accepted for this status. To me Open is the antonym of Closed rather than a specific stage. But I agree with the extra step. In Progress means, er, in progress
–
AndrewNov 15 '12 at 7:33

1

Seems reasonable. Every shop uses different words and more/fewer stages. For example, in my shop we distinguish VERIFIED (the tester has verified the fixed bug), from CLOSED (the fixed code has been released to Production).
–
Joe StrazzereNov 15 '12 at 12:14

Over and above the suggestions already made, we also have an extra step in Stage 2 of Feedback which is used if the assessor(s) require(s) further information or clarification before being able to Accept/Reject the issue.

When Dev manager REJECT the issue and it comes to QE and QE doesn't agree with REJECTION then QE can assign that issue to PM(Product Manager), now issue is still OPEN. PM then matches the requirement and may assign issue to Dev manager to fix it OR assign to tester to close OR change issue into Enhancement.

Sounds simple and strange at one time, so heres the explanation and where it comes from:

We use redmine as issue-tracker. There you can define your states by giving them names and if they should count as "closed". Here are some of our states:

"New" -> Open

"In Progress" -> Open

"To be tested" -> Open

"Resolved" -> Open

"Rejected", definied as Closed -> Closed

"Closed", definied as Closed -> Closed

So when we changed a new issue, lets say a duplicate of an already posted bug, to "Rejeceted" we close the ticket, even it's not in the status "Closed". So when we filter for "open issues" we wont see this ticket in the result.

To answer your question: Depending of how your team definies the meaning of "Rejected" i would guess that your issues are "open" as long as they are not in the status "Closed" (or maybe rejected, see above). But as Sam Woods mentioned - it depends on the defintion made by the team. Make sure to speak about the same.