Defect Management: Bug Lifecycle, Severity vs Priority, and Triage
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)
| Level | Definition | Example |
|---|---|---|
| Critical | System crash, data loss, security breach | Application crashes on login |
| Major | Major feature broken, no workaround | Payment processing fails |
| Minor | Feature partially broken, workaround exists | UI alignment issue |
| Trivial | Cosmetic issue, no functional impact | Typo in tooltip text |
Priority (Business Urgency)
| Level | Definition | Response Time |
|---|---|---|
| P0 | Blocking release, immediate action | 1-4 hours |
| P1 | Must fix in current sprint | 24 hours |
| P2 | Should fix, but can wait for next sprint | 1 week |
| P3 | Nice to have, backlog item | Next release |
| P4 | Deferred indefinitely | Unscheduled |
Matrix
| Critical | Major | Minor | Trivial | |
|---|---|---|---|---|
| P0 | Fix immediately | Patch ASAP | — | — |
| P1 | Fix this sprint | Fix this sprint | Fix this sprint | — |
| P2 | Fix next sprint | Fix next sprint | Fix next sprint | Fix next sprint |
| P3 | — | Backlog | Backlog | Backlog |
| P4 | — | — | — | Maybe 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
- Review new bugs — classify severity, assign priority
- Re-evaluate existing bugs — has priority changed? Is more info needed?
- Check for duplicates — merge related reports
- 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, backlogTriage 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
| Tool | Best For | Key Features |
|---|---|---|
| Jira | Enterprise teams | Custom workflows, sprint management, reporting |
| GitHub Issues | Open source, small teams | Labels, milestones, project boards |
| GitLab Issues | GitLab users | Boards, weight estimation, SLAs |
| Linear | Fast-moving teams | Keyboard-first, AI triage, cycle tracking |
| Bugzilla | Legacy projects | Mature, 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
What’s Next
| Tutorial | What You’ll Learn |
|---|---|
| Test Automation Frameworks | Automating testing to prevent regressions |
| Quality Metrics and Measurement | Measuring defect trends over time |
| Continuous Testing in CI/CD | Catching 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