Skip to content
Defect Management: Bug Lifecycle, Severity vs Priority, and Triage

Defect Management: Bug Lifecycle, Severity vs Priority, and Triage

DodaTech Updated Jun 20, 2026 7 min read

Defect management is the systematic process of identifying, documenting, classifying, prioritizing, and resolving software bugs — ensuring that issues are tracked from discovery through verification and closure with clear ownership at every stage.

What You’ll Learn

  • The complete bug lifecycle: new, assigned, open, fixed, verified, closed
  • The difference between severity and priority and how to classify both
  • How to run an effective bug triage process
  • How to write clear, actionable bug reports
  • Common defect management pitfalls and best practices

Why Defect Management Matters

Without a structured defect management process, bugs get lost, duplicated, or forgotten. Critical issues sit unresolved while minor annoyances get immediate attention. Teams waste time on unclear reports, arguing about priority, or rediscovering the same bug. A systematic approach ensures that the most important bugs get fixed first, nothing falls through the cracks, and the team has clear data about product quality over time.

Durga Antivirus Pro has a dedicated defect management process for vulnerability reports — each potential threat is triaged within 4 hours to determine whether users are at risk.

Learning Path

    flowchart LR
  A[Quality Metrics] --> B[Defect Management<br/>You are here]
  B --> C[Test Automation]
  C --> D[Continuous Testing]
  D --> E[Production Monitoring]
  style B fill:#f90,color:#fff
  

The Bug Lifecycle

Every bug follows a standard lifecycle:

    flowchart LR
  A[New] --> B[Assigned]
  B --> C[Open]
  C --> D[Fixed]
  D --> E[Verified]
  E --> F[Closed]
  C --> G[Reopened]
  G --> C
  F --> H[Reopen]
  H --> C
  

Stage Details

New: The bug has been reported and is in the backlog, unassigned.

Assigned: A developer has been assigned to investigate and fix the bug.

Open: The developer has confirmed the bug and is working on a fix.

Fixed: A fix has been committed and deployed to a test environment.

Verified: The QA team has confirmed the fix works in the test environment.

Closed: The fix is deployed to production and verified.

Reopened: The bug resurfaced — the fix was incomplete, the environment differed, or the root cause wasn’t fully addressed.

Severity vs Priority

These are often confused but serve different purposes:

Severity (Impact on System)

LevelDefinitionExample
CriticalSystem crash, data loss, security breachApplication crashes on login
MajorMajor feature broken, no workaroundPayment processing fails
MinorFeature partially broken, workaround existsUI alignment issue
TrivialCosmetic issue, no functional impactTypo in tooltip text

Priority (Business Urgency)

LevelDefinitionResponse Time
P0Blocking release, immediate action1-4 hours
P1Must fix in current sprint24 hours
P2Should fix, but can wait for next sprint1 week
P3Nice to have, backlog itemNext release
P4Deferred indefinitelyUnscheduled

Matrix

CriticalMajorMinorTrivial
P0Fix immediatelyPatch ASAP
P1Fix this sprintFix this sprintFix this sprint
P2Fix next sprintFix next sprintFix next sprintFix next sprint
P3BacklogBacklogBacklog
P4Maybe never

Writing Effective Bug Reports

A good bug report makes it easy for developers to understand and reproduce the issue:

## Bug: Login fails with special characters in password

**Severity**: Major
**Priority**: P1
**Environment**: Production (Chrome 120, Windows 11)

### Description
Users with special characters (@, #, $) in their password cannot log in.
The form shows a generic "Invalid credentials" error.

### Steps to Reproduce
1. Go to https://example.com/login
2. Enter email "test@example.com"
3. Enter password "Pass@123#"
4. Click "Sign In"

### Expected Result
User is logged in and redirected to dashboard.

### Actual Result
Form shows "Invalid credentials" error. No network request is made to the
login endpoint, suggesting client-side validation is rejecting the password.

### Additional Context
- Works correctly with alphanumeric-only passwords
- Error appears in console: "ValidationError: Password contains invalid chars"
- Bug was introduced in release 2.4.0 (commit a1b2c3d)

Bug Triage Process

Triage is the process of reviewing new bugs to determine severity, priority, and assignment. Run triage daily or at least every 2-3 days:

Triage Meeting Agenda

  1. Review new bugs — classify severity, assign priority
  2. Re-evaluate existing bugs — has priority changed? Is more info needed?
  3. Check for duplicates — merge related reports
  4. Assign owners — assign to developers or defer

Triage Decision Tree

Is the bug security-related?
  ├─ Yes → P0, assign to security team
  └─ No → Is the bug blocking a release?
           ├─ Yes → P0-P1, assign to release-affected team
           └─ No → Does the bug affect core functionality?
                    ├─ Yes → P1-P2, assign to feature owner
                    └─ No → P3-P4, backlog

Triage Roles

  • Triage Lead: Facilitates the meeting, makes final priority decisions
  • Reporter: Provides context and reproduction steps
  • Developer: Estimates fix complexity and provides technical input
  • QA: Verifies reproduction and will later verify the fix

Defect Tracking Tools

ToolBest ForKey Features
JiraEnterprise teamsCustom workflows, sprint management, reporting
GitHub IssuesOpen source, small teamsLabels, milestones, project boards
GitLab IssuesGitLab usersBoards, weight estimation, SLAs
LinearFast-moving teamsKeyboard-first, AI triage, cycle tracking
BugzillaLegacy projectsMature, highly customizable

Common Defect Management Mistakes

1. Poor Bug Reports

“App doesn’t work” or “Login is broken” without steps to reproduce wastes everyone’s time.

Fix: Use a bug report template with required fields: description, steps, expected vs actual result, environment.

2. Not Prioritizing

Every bug marked “critical” means no bugs are truly critical. Without priority, teams fix whatever is easiest.

Fix: Use a severity/priority matrix. Triage new bugs within 24 hours.

3. Triage Avoidance

Bugs pile up in “New” status because no one wants to make priority decisions.

Fix: Schedule daily or tri-weekly triage. Limit triage to 15 minutes.

4. Letting Bugs Accumulate

Bug counts of 500+ in the backlog are overwhelming. Most will never be addressed.

Fix: Regularly cull the backlog. Close bugs that are years old, unreproducible, or no longer relevant.

5. No Bug Baselines

Without tracking bug counts over time, you can’t tell if quality is improving.

Fix: Track open bug count, new bug rate, and closure rate weekly.

6. Blaming Instead of Fixing

“Who wrote this?” creates fear and discourages reporting.

Fix: Focus on the process, not the person. Ask “how did this escape detection?” not “who wrote this code?”

7. Ignoring Bug Patterns

Fifty bugs in the same module indicate a systemic problem — rewriting or redesigning may be cheaper than fixing each bug.

Fix: Investigate clusters of bugs. A few modules usually account for most defects.

Practice Questions

1. What are the six stages of the bug lifecycle?

New, Assigned, Open, Fixed, Verified, Closed (with Reopened as an additional state).

2. What is the difference between severity and priority?

Severity measures technical impact (how bad is the bug). Priority measures business urgency (how fast it must be fixed).

3. What information should every bug report include?

Description, steps to reproduce, expected vs actual result, environment, severity, and priority.

4. What is bug triage and how often should it happen?

Triage is classifying and prioritizing new bugs. It should happen daily or every 2-3 days.

5. How do you handle duplicate bug reports?

Merge duplicates into the original report. Link them so reporters and watchers are consolidated.

Challenge: Set up a bug tracking system for a project (can be a real project or a hypothetical one). Define severity and priority levels, create a triage workflow, and write a process document. Practice triaging 10 bugs with different severities and priorities.

FAQ

Who should triage bugs?
A cross-functional team including a developer, QA engineer, and product manager. A designated triage lead makes final decisions.
How many bugs is too many?
Track the trend. If open bugs increase week over week, you’re finding bugs faster than fixing them. Investigate why.
Should I file a bug for every issue?
File bugs for any issue that affects users. For internal issues (code quality, technical debt), use a separate tracking mechanism or label.
How do I get developers to fix bugs?
Make bugs visible, prioritized, and accounted for in sprint planning. Dedicate 20-30% of each sprint to bug fixes.
What is the ideal time to fix a P0 bug?
P0 bugs should have someone investigating within 1 hour and a fix deployed within 4 hours.

What’s Next

TutorialWhat You’ll Learn
Test Automation FrameworksAutomating testing to prevent regressions
Quality Metrics and MeasurementMeasuring defect trends over time
Continuous Testing in CI/CDCatching bugs earlier in the pipeline

Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. Updated 2026-06-20.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro