Defect management: severity, triage and the defect lifecycle

A defect in payments is not just a bug, it is a risk to customer money. A defect that causes a payment to be sent to the wrong beneficiary, to be sent twice, or to be lost, is a critical defect, and it must be fixed before the release. A defect that causes a status to be displayed incorrectly is a major defect, because the customer will act on the wrong information. A defect that causes a cosmetic issue in the payment history is a minor defect. The severity must be assigned by the impact on the customer and on the money, not by the difficulty of the fix. Triage is the meeting where defects are prioritised, and in payments it must happen daily during testing. The triage team includes the product owner, the test lead, the development lead, and the operations lead, because each one sees a different part of the impact. The product owner knows the business impact, the test lead knows the test coverage, the development lead knows the fix effort, and the operations lead knows the production impact. A defect that is triaged by only one person will be mis-prioritised, and a mis-prioritised defect will either delay the release unnecessarily or escape into production. The defect lifecycle has a fixed sequence: new, assigned, in progress, fixed, retested, closed, or reopened. A defect that is fixed but not retested is not closed, it is waiting. A defect that is retested and fails is reopened, and the reopen count is a metric that matters, because a defect that is reopened three times indicates a deeper problem. The defect record must include the steps to reproduce, the expected result, the actual result, the severity, the priority, the owner, and the release in which it was found. A defect without steps to reproduce cannot be fixed. Root cause analysis for a defect asks why it happened, not just what happened. A defect where a payment was sent twice might have been caused by a missing idempotency check, but the root cause might be that the retry logic was not specified, or that the test pack had no duplicate test, or that the code review did not catch it. The analysis must find the process failure behind the technical failure, because fixing the code without fixing the process will produce the same defect again. The analysis must be documented, and the process fix must be tracked as an action. Production defects are handled differently from test defects, because the money is already at risk. A production defect that causes duplicate payments must trigger an immediate incident, a halt to new payments if necessary, and a reconciliation to find every affected payment. The defect must be fixed, the affected payments must be corrected, the customers must be told, and the regulator must be notified if the impact meets the threshold. A production defect that is treated as a routine bug will become a regulatory incident. Defect metrics are the management tool. The metrics include the number of defects by severity, the time to fix, the reopen rate, the escape rate, which is the percentage of defects found in production rather than in testing, and the defect density, which is the number of defects per thousand lines of code or per test case. A rising escape rate means the testing is not working, and the test strategy must be reviewed. The metrics must be reported weekly during testing, and the trend must be visible to the product owner. For a business analyst, the defect process is a set of requirements. The requirements must state the severity definitions, the triage process, the lifecycle, the root cause analysis, and the metrics. The acceptance criteria must include a test where a defect is raised, triaged, fixed, retested and closed, with the full lifecycle recorded. Last reviewed 7 November 2026. Further reading: the International Software Testing Qualifications Board syllabus; the IEEE Standard for Software and System Test Documentation; the EPC SEPA test packs; the Bank of England guidance on payment system defect management.