This page needs a technical review from the Mozilla QA Team in Q4 2014. (Assigned to Liz Henry.) This article has been created from A Bug’s Life on QMO.

Overview

Bug States

1. Unconfirmed
2. New
3. Assigned
4. Resolved
5. Reopened
6. Verified

Hi, and welcome to QA at Mozilla! The reason you're probably here is to find out what we do here and how we do it. Well, if you're interested in what goes on in Mozilla's bug tracking tool, Bugzilla , then you've come to the right document. This tutorial will give an overview of what happens in the states that a filed bug, on Firefox's main development trunk, will go through, as well as how it will go from one state to the next within its life. There's a nice image that graphically shows what happens, but we feel that its a bit too much to comprehend in the first go-around.

For each state a bug can be in, we'll look at: How did the bug get here? What happens in this state? What are the possible states it can go to from here?

Tutorial

1. UNCONFIRMED

-How did it get here?

• A bug is created by a new or inexperienced user and is waiting for confirmation by a Mozilla QA Community Member.

• A MozQA Community Member will confirm that they can reproduce the bug. They should add a comment to the bug, mentioning their Build ID, as well as any additional comments that might help in fixing the issue.
• If you want to help confirm newly reported bugs, here is a bug triage tutorial!

-What are the possible states it can go to from here?

• NEW: The bug has been confirmed by a MozQA Community Member. Please refer to Confirming Unconfirmed Bugs for more information.
• RESOLVED: DUPLICATE - A previous bug was filed earlier whose behavior is exactly the same as the current one.
• RESOLVED: WONTFIX - The community agrees that the issue is something that either cannot or will not be fixed. A comment, or discussion, needs to occur before the decision is made. This decision is usually made by developers, not by QA.
• RESOLVED: WORKSFORME - The bug is no longer reproducible on the same platform and OS the original bug reporter used, but it's unknown how the problem has been fixed.
• RESOLVED: INVALID - The bug is not something that we consider Mozilla's bug, or isn't a situation that would normally occur. It may also be a support question, not a bug.
• RESOLVED: INCOMPLETE - The bug is vaguely described with little to no steps to reproduce.

2. NEW

-How did it get here?

• A bug has been confirmed by a MozQA Community Member, but a developer hasn't yet picked it up to fix.

-What happens in this state?

• A developer looks at the bug and volunteers to fix the issue.

-What are the possible states it can go to from here?

• ASSIGNED - One of the developers will pick up the bug and volunteer to fix the bug.
• RESOLVED - Someone may fix the bug without ever assigning it to themselves.

3. ASSIGNED

-How did it get here?

• A developer thinks the bug's scenario is accurate, testable and should be fixed. They have picked up the bug and begin to investigate it.

-What happens in this state?

• A developer takes possession of the bug and begins the process of investigating and fixing it.

-What are the possible states it can go to from here?

• RESOLVED - The MozDev Community Member has submitted a patch, someone has reviewed their patch, and it's been merged with a main code repository.

4. RESOLVED

-How did it get here?

• A sheriff merges the bug fix, or patch, with one of Mozilla's code repositories, such as Nightly ("trunk", or "mozilla-central"). Either a fix was pushed to the next firefox nightly build or the bug's state was resolved with one of the solutions listed below. 

-What happens in this state?

• A community member verifies the developer's fix on the latest nightly build that the bug was pushed to. This is a good task for QA community members!

-What are the possible states it can go to from here?

• REOPENED - Someone figures out that the issue is not fixed. The bug is reopened so a developer will see it.

-What are the possible resolutions it can be assigned to here?

• FIXED - In the version visible in field Target Milestone shows the earliest version where the bug reporter's issue has become fixed.
• DUPLICATE - Someone has found an existing bug that reports the same issue.
• WONTFIX - A developer decides the issue is something that can't or won't be fixed.
• WORKSFORME -
  • Despite intensive attempts it has been impossible to reproduce reporter's problem on the same platform, operating system and version; the problem seems to depend on reporter's installation, not on the software application
    
    or
     
  • The problem has vanished, but it's unknown how it has become fixed. Field Target Milestone shows the eariliest known version behind contents of BZ-field Version without the problem.
• INVALID - This isn't a bug, isn't a Mozilla bug, or is better addressed as a support issue.
• INCOMPLETE - The bug has little to no steps to reproduce.

5. REOPENED

-How did it get here?

• The issue still occurs on the latest nightly build.

-What happens in this state?

• A developer will investigate the issue again.

-What are the possible states it can go to from here?

• ASSIGNED - A developer has taken the bug to try and fix it.
• RESOLVED: FIXED - The developer has fixed the issue.

6. VERIFIED

-How did it get here?

• The resolution of the bug was verified by a MozQA Community Member. Its useful life is finally complete!

Hopefully, this walk through has provided you with a good idea of what goes on from state to state with a filed bug (on the main trunk) on Bugzilla. If you feel like there's a question, comment or even a suggestion that you'd like to bring up, please mention it in irc, on #qa on irc.mozilla.org.

Original document information

Want to Know More?

Ready to start filing bug reports? Find out how to write a good bug report.

• Author(s): Aakash Desai
• Date last modified: May 27, 2010 at 1:45 pm PST