Currently I have been assigned to a new project and I saw few defects with status "Open" in the defect tracker (which is an Excel sheet).

Below is my understanding of Defect Life sheet.

  1. When a new Defect is found then STATUS = New
  2. Now the defect will be evaluated by dev team manager:

    i.If the defect is not valid then STATUS = Rejected

    ii.If defect is out of scope then STATUS = Differed

    iii. If defect is a duplicate then STATUS = Duplicate

  3. If the defect is valid, in scope and is not a duplicate then STATUS = In-Progress.

  4. Once the defect is fixed by Developer then STATUS = Fixed.
  5. Now the defect will be re-tested by tester:

    i. Defect is Fixed then STATUS = Closed.

    ii. Defect is still not closed then STATUS =Re-Open.

So where do you think I have misunderstood the defect life cycle? Feel free to correct me.


  • 5
    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. Commented Nov 14, 2012 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.
    – Garv
    Commented Nov 14, 2012 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.
    – dzieciou
    Commented Nov 15, 2012 at 7:51

7 Answers 7


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.


Many shops would have an additional outcome to your step 2.

  1. Now the defect will be evaluated by dev team manager:

    i.If the defect is not valid then STATUS = Rejected

    ii.If defect is out of scope then STATUS = Deferred

    iii. If defect is a duplicate then STATUS = Duplicate

    iv. If the defect is none of these, then STATUS = Open

(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.)

Your mileage may vary.

  • 1
    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
    – Andrew
    Commented Nov 15, 2012 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). Commented Nov 15, 2012 at 12:14

Answers above are correct, let me make just a small re-phrasing of above answers.

Depending on a bug/issue tracker software, there are several attributes of Issue.
Status and Openness may be combined or separated.

The common reason for having Openness separated is the consideration that

an issue should be closed by the same user who has opened it.

I don't argue if this statement is valid or not. It may be defined by each team's QA process definition. For those who accept this statement, having Openness attribute separate is obviously required:

  • An new issue is Open/New
  • Rejected/Confirmed/InProgress is still Open
  • Fixed issues go to the initial QA engineer, and they either Closed/Verified it, or make them Open/Reopen
  • Good distinction.
    – Andrew
    Commented Nov 15, 2012 at 7:34

When Bug state are - NEW, FIXED, IN-PROGRESS, ANALYZE, RESOLVED, SUBMITTED etc. we say bug is in open state.

When Bug state are - REJECTED, DUPLICATE, DEFERRED, NFA(No Further action),closed, VERIFIED etc . we say bug is in close state.


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.


One more condition may come up at Step 2:

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.


Well in our project we keep this question quite simple:

All status that are not defined as "closed" are open.

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.