Understanding Bug Statuses in Deskfactor

Deskfactor uses bug statuses to provide real-time visibility into where a reported issue stands within your team’s quality assurance and resolution lifecycle.
Clear status tracking helps developers, testers, and project managers instantly identify who holds the next action item and whether an issue has been successfully addressed. This guide covers all available bug statuses, the standard tracking workflow, and best practices for maintaining accurate quality metrics.

Available Bug Statuses in Deskfactor

Deskfactor features eight distinct bug statuses to capture every phase of the resolution pipeline:

1. New
2. Assigned
3. In Progress
4. Ready for Review
5. Under Review
6. Resolved
7. Rejected
8. Not a Bug

Detailed Status Definitions and Examples

1. New

• Definition: The initial status of a newly reported bug before it has been evaluated or assigned.
• When to use: When an issue is first submitted by a tester or team member, awaiting review and assignment.
• Example: A tester identifies an unexpected validation error while testing a feature and submits a bug report. It remains New until a project manager reviews and routes it.

2. Assigned

• Definition: Indicates that the bug has been assigned to a specific developer or team member responsible for fixing it.
• When to use: When ownership is established, though active work may not have started yet.
• Example: A Project Manager evaluates a new bug report and assigns it to the software engineer responsible for that module.

3. In Progress

• Definition: Indicates that the assigned developer is actively investigating or working on the issue.
• When to use: While reproducing the bug, diagnosing root causes, writing code patches, or running local tests.
• Example: The developer begins troubleshooting the error, moves the ticket to In Progress, and works on implementing a fix.

4. Ready For Review

• Definition: Signifies that the developer has completed the code fix and verified it locally, making the bug ready for QA testing.
• When to use:Immediately after a developer finishes coding and testing the fix in a local or staging environment.
• Example: A developer resolves a broken layout bug, tests the layout across screen sizes, and changes the status to Ready for Review.

5. Under Review

• Definition: Indicates that a tester is actively verifying the bug fix in the testing environment.
• When to use: While the tester reproduces the original steps and checks for regressions.
• Example: A QA engineer picks up a ticket marked Ready for Review and shifts it to Under Review while validating the fix.

6. Resolved

• Definition: Confirms that the fix has been successfully verified by a tester and the issue no longer occurs.
• When to use: When a bug passes verification, marking the successful completion of the workflow.
• Example: The tester re-runs the original failure scenario, confirms the application works as expected, and marks the bug as Resolved.

7. Rejected

• Definition: Indicates that the tester reviewed the developer’s fix, but the issue is still reproducible or was not fixed correctly.
• When to use: When a fix fails QA validation, requiring the developer to resume work.
• Example: A tester tests a fix marked “Ready for Review,” discovers the original error still happens, and marks it Rejected to send it back to the developer.

8. Not a Bug

• Definition: Applied when a reported issue is reviewed and determined not to be an actual software defect.
• When to use: When troubleshooting reveals that the behavior is expected or outside project scope. This may happen when:
  • The application operates strictly according to approved requirements.
  • The behavior is intentional and expected.
  • The issue stems from user error, incorrect usage, or a misunderstanding.
  • The expectation falls outside the agreed project scope.
  • Further inspection confirms zero defects in code
• Example: A user reports that a settings button is missing. After checking permissions, the team realizes the user’s role lacks access to that feature. Because the app behaves as designed, the ticket is marked Not a Bug.

Typical Bug Workflows

Understanding how tickets transition through different stages helps teams maintain clean tracking hygiene.

Standard Successful Resolution Flow

Iterative Flow (Failed Verification)

If a fix fails testing, the workflow loops back for rework:

Invalid Issue Flow

If an issue is found to be invalid, it can be filtered out early:

(Note: The exact transistion path may vary depending on when an issue is identified as invalid.)

Resolved vs. Rejected vs. Not a Bug

To keep your bug tracking clean and metrics accurate, it is vital to understand the difference between these three final-stage classifications:

Benefits of Using Accurate Bug Statuses

Keeping bug statuses up to date empowers your entire team to:

• Instantly see the current stage of any reported issue.
• Identify ownership and determine who needs to take the next action.
• Track bottlenecks between developer implementation and tester verification
• Clearly differentiate successful fixes from failed patches
• Filter out invalid reports ( Not a Bug) to protect the integrity of the quality metrics and defect density reports
• Maintain a transparent, searchable audit history of the development lifecycle.