Beginner-Friendly Topic
Take your time - it's perfectly normal to re-read this topic 2-3 times. Try the interactive code editor below to run code yourself. Use the Q&A section to check your understanding before moving on. You've got this! 🚀
Defect Triage & Retesting
Defect triage is the process of reviewing newly filed bugs to assign priority, severity, ownership, and target release. Retesting is the structured verification that a bug fix actually works. Both processes are essential for maintaining a healthy defect backlog and ensuring fixes don't introduce new problems.
The Defect Triage Process
- Who attends: Test lead, development lead, product manager, sometimes UX and security teams
- Frequency: Daily during active testing phases; weekly during maintenance
- Triage decisions: Is this actually a bug (vs. expected behavior or duplicate)? What is the correct severity/priority? Who owns the fix? Which release should it target?
- Deduplication: Check if the bug is already filed before triage to avoid duplicate fixes
- Risk assessment: Does this bug block the release? Does it require a hotfix or can it wait?
Retesting Protocol
// ══════════════════════════════════════════════════════════════
// RETESTING CHECKLIST - after developer marks a bug FIXED
// ══════════════════════════════════════════════════════════════
// Step 1: Confirm the fix is deployed to the TEST environment
// (not just the developer's local machine)
// Verify: App version in staging = version developer deployed
// Step 2: Reproduce the original bug using the EXACT original steps
// Do NOT use different steps - reproducing with different steps
// doesn't confirm the original bug was fixed
// Step 3: Verify the expected result is now met
// ✅ If YES → Mark bug as VERIFIED → CLOSED
// Step 4: Regression check - test related functionality
// The fix for Bug A can break Bug B (regression)
// Related areas to regression-test after login fix:
// - "Remember Me" functionality
// - Password reset flow
// - OAuth/SSO login
// - Session timeout behavior
// Step 5: Cross-environment verification (if applicable)
// If bug was on Safari only → verify fix on Safari specifically
// If bug was environment-specific → verify on SAME environment
// ══════════════════════════════════════════════════════════════
// TRIAGE MEETING - Real Scenario
// ══════════════════════════════════════════════════════════════
// BUG-089: "Checkout crashes on iPad Mini portrait mode"
// Filed by: Alice (QA)
// Initial severity: Critical
// Triage discussion:
// - Product: "iPad Mini usage is 0.8% of our users"
// - QA: "Crash is confirmed, not just visual - cart data lost"
// - Dev: "It's a CSS grid issue, fix is 2-3 hours"
// - PM decision: Severity = Major (data loss), Priority = Medium
// (affects <1% users, workaround: landscape mode works)
// Target: Next sprint (not current release blocker)
// Triage outcome recorded:
// Severity: MAJOR | Priority: MEDIUM | Owner: Frontend Team
// Target Release: v2.4.2 | Status: DEFERREDCommon Mistakes
- Retesting only the fixed scenario - without regression testing adjacent features, fixes frequently break something nearby
- Retesting on the wrong environment - if bug was on staging, verify the fix on staging, not the developer's local machine
- Not verifying with the exact original steps - using different reproduction steps may pass, but the original scenario may still be broken
- Skipping triage for 'obvious' bugs - even obvious bugs need triage to ensure correct owner, priority, and release targeting
Tip
Tip
Practice Defect Triage Retesting in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Technical diagram.
Practice Task
Note
Practice Task - (1) Write a working example of Defect Triage Retesting from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Defect Triage Retesting is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Defect triage is the process of reviewing newly filed bugs to assign priority, severity, ownership, and target release.
- Who attends: Test lead, development lead, product manager, sometimes UX and security teams
- Frequency: Daily during active testing phases; weekly during maintenance
- Triage decisions: Is this actually a bug (vs. expected behavior or duplicate)? What is the correct severity/priority? Who owns the fix? Which release should it target?