Leonardo_Vision_XL_People_discussing_about_the_issue_through_t_0

Levels of Defects: Complete Guide with Examples, Responsibilities & Documentation

Understanding defect levels helps teams properly categorize, prioritize, and resolve issues. Here’s a detailed breakdown with real-world examples from e-commerce (using Myntra as reference):

1. Defect Classification by Level

LevelDefinitionResponsible RoleDocuments RequiredMyntra Example
CriticalBlocks core functionality/system crashQA Lead + Dev ManagerIncident Report, Crash LogsPayment gateway failure during checkout
MajorKey features not working as expectedSenior DeveloperBug Report with Reproduction Steps“Add to Cart” button non-functional
ModeratePartial functionality lossQA Engineer + DeveloperTest Case Failure DocumentationProduct filters not sorting correctly
MinorCosmetic/low-impact issuesJunior DeveloperUI Snapshot, Style Guide ReferenceMisaligned text in footer
TrivialTypos/very minor UI glitchesFrontend DeveloperChange Request Form“Shoses” instead of “Shoes” in category

2. Detailed Explanation of Each Level

A. Critical Defects (Level 1)

Impact: System outage or data loss
Resolution Time: Immediate (within 24 hours)
Process:

  1. QA files incident report with stack traces
  2. Dev ops team is alerted via PagerDuty
  3. Hotfix deployment with rollback plan

Example:

  • Scenario: Myntra’s order database not updating after payments
  • Action:
  • QA attaches payment gateway logs
  • Database admin restores backup
  • Dev team patches SQL transaction bug

Documents:

  • Incident report (Root Cause Analysis)
  • Server/application logs
  • Hotfix deployment checklist

B. Major Defects (Level 2)

Impact: Core feature failure
Resolution Time: 2-3 days
Process:

  1. Detailed bug report with video evidence
  2. Added to current sprint backlog
  3. Requires regression testing after fix

Example:

  • Scenario: Wishlist items disappear after app restart
  • Action:
  • QA records screen video
  • Mobile dev fixes local storage issue
  • Testers verify across iOS/Android versions

Documents:

  • JIRA/Bugzilla ticket with attachments
  • API response samples (if applicable)
  • Regression test plan

C. Moderate Defects (Level 3)

Impact: Workaround exists but degrades UX
Resolution Time: Next release cycle

Example:

  • Scenario: Size guide shows incorrect measurements for jeans
  • Action:
  • QA attaches product catalog data
  • Backend team corrects size chart API
  • Verified in staging before production

Documents:

  • Test data sheets
  • API specification updates
  • Staging verification report

D. Minor Defects (Level 4)

Impact: Visual inconsistencies
Resolution Time: Can wait for major releases

Example:

  • Scenario: Heart icon misaligned on product cards
  • Action:
  • UX designer provides corrected margins
  • Frontend dev updates CSS
  • Visual QA sign-off

Documents:

  • UI screenshot with annotations
  • Style guide compliance form
  • CSS change log

E. Trivial Defects (Level 5)

Impact: Doesn’t affect functionality
Resolution Time: Batched with other minor fixes

Example:

  • Scenario: “Shippng” typo in order confirmation email
  • Action:
  • Content writer submits correction
  • Added to next email template update

Documents:

  • Content change request
  • Localization spreadsheet update

3. Defect Level Workflow Example (Myntra Case)

Defect: “Apply Coupon” button fails during flash sale

  1. Identification:
  • QA engineer finds issue during load testing
  • Classifies as Critical (direct revenue impact)
  1. Documentation:
  • Files JIRA ticket with:
    • Load test results (5000 concurrent users)
    • Payment gateway error logs
    • Screen recording
  1. Resolution:
  • Dev ops scales up coupon service containers
  • Backend team optimizes database queries
  • Fix deployed with 1-hour monitoring
  1. Verification:
  • QA retests with 2x expected traffic
  • Finance team confirms no order losses
  • Ticket marked Closed with post-mortem report

4. Key Documents for Defect Management

DocumentUsed ForTemplate Components
Incident ReportCritical defectsTimeline, Impact, RCA, Resolution Steps
Bug ReportMajor/Moderate defectsSteps to Reproduce, Expected vs Actual
Test Case Failure LogAll defectsLinked test case ID, Environment details
Regression Test ChecklistPost-fix verificationAffected areas, Test data versions
Defect Trend AnalysisMonthly quality reportsSeverity distribution, Reopen rates

5. Best Practices for Defect Level Management

  1. Clear Classification Guidelines
  • Maintain a shared severity matrix (e.g., “Any checkout failure = Critical”)
  1. Escalation Protocols
  • Critical defects: Immediate Slack/Teams alert to managers
  • Major defects: Daily standup updates
  1. Documentation Standards
  • Always include:
    • Environment (iOS 15.3, Chrome v102)
    • Timestamp of occurrence
    • Business impact (e.g., “15% cart abandonment”)
  1. Review Process
  • Weekly defect triage meetings to reclassify if needed

6. Real-World Priority vs Severity Scenario

Situation at Myntra:

  • Critical Severity: Address validation API failing for 0.1% pincodes
  • Major Severity: “Trending Styles” carousel broken for all users

Decision:

  • Higher Priority: Carousel fix (visible to all users daily)
  • Lower Priority: Niche API fix (scheduled next release)

Why? Business impact > technical severity in this case


Conclusion

Proper defect level classification:
Ensures critical issues get immediate attention
Prevents developer overload from minor bugs
Provides data for quality trend analysis

Pro Tip:
“Treat defect levels like hospital triage – not all patients need the ER, but all need proper care.”

34 Responses

Add a Comment

Your email address will not be published. Required fields are marked *