Defect Triage Conflict Across Teams
During system testing, a tester reports that an order-confirmation email is sent twice when a payment callback times out and retries. The payments team owns the callback; the notifications team owns the email. Each says the other should deduplicate. The defect sits unassigned for 5 days. Severity is marked major, but the product owner argues customers just get a duplicate email, so it is minor. Meanwhile, a separate high-severity defect in the same area causes missing confirmations entirely. The test lead must drive triage before the test phase ends in 4 days.
1. How should the test lead resolve the ownership deadlock and the severity dispute?
Read the worked answer
Ownership: the defect crosses a boundary, so the test lead should assign it to the component that can most reliably prevent duplicates. Idempotency is usually best enforced at the consumer or at the callback handler using a unique event or order identifier. Rather than let the teams argue, the lead should convene a short triage with both owners, agree on the fix location, and record the decision. Boundary defects need an explicit owner, not shared blame.
Severity: the product owner is partly right that a duplicate email alone is minor in isolation. But the same root cause (retry handling) also produces missing confirmations, which is high severity. The test lead should link the two defects, show they share a cause, and re-rate the duplicate as a symptom of a higher-risk defect. Severity should reflect the worst credible outcome of the underlying fault, not just the first observed symptom. Document the reasoning so the rating is defensible.
2. What process improvements would you recommend after this incident, and how would you verify they work?
Read the worked answer
Recommend: (1) a defined triage cadence and an escalation path so unassigned defects have a deadline and an owner; (2) explicit ownership rules for cross-component features, agreed before testing starts; (3) severity criteria that tie to business impact and consider shared root causes, so related defects are grouped; (4) a review of retry and idempotency design across the payment and notification boundary, since the same fault produced two symptoms.
Verification: track time-to-assignment and time-to-fix for cross-team defects over the next two sprints, and confirm no defect sits unassigned beyond the agreed threshold. Add targeted tests for timeout-and-retry scenarios, asserting a single confirmation on success and a confirmation on eventual success. Confirm the linked defects are fixed together and regression-tested. Measure whether duplicate and missing confirmation defects recur; a drop to zero across two releases is reasonable evidence the fix and the process change both hold.