A bug is a flaw in software. A defect is another name for that same flaw. An incident is an unplanned interruption of a running service, or a reduction in its quality. A technical debt item records a shortcut or an aged design that makes later change slower or riskier, and the software can still meet its specification.
The cent, the double charge, and the copy-paste
Fictional Lantern Works has three rows that engineers keep merging. In test, tax rounds down by one cent. On a Saturday that never happened except in this example, buyers are charged twice for sixteen minutes. The tax function is also pasted four times, the tests pass, and every change takes a day that should have taken an hour. Calling all three "bugs" makes the outage look like a backlog item and the paste look like a broken specification.
Defect is a name for the bug
A bug is recorded as a work item so it can be corrected. The registry lists defect, software defect, and software bug as synonyms, not as further concepts. Testing glossaries treat bug, defect, and fault as that flaw in a work product. Some organizations use defect for a flaw found after release and bug for one found before. That split records when it was found, so both words still name this concept. The one-cent rounding, found before any buyer is harmed, is a bug. Calling it a defect does not create a second entity.
Bug severity grades the flaw: how far behavior departs from what was specified or expected. The one-cent miss is not the same grade as a crash. Severity does not say when the team will fix it. Steps to reproduce are evidence on the bug. They are not the severity and not the correction.
A failure is a loss of ability to operate to specification or to deliver the required outcome. The word error is not a synonym of this flaw. The Information Technology Infrastructure Library (ITIL) uses error for a flaw or vulnerability that may cause incidents. Software testing uses error for the human mistake that introduces a defect. Dependability writing uses error for a wrong internal state. A known error is a problem that has been analysed and has not been resolved. It is a name for that problem, not for this flaw. A failed request in a log is not, by itself, a bug record.
An incident is harm to a running service
The double charge is the incident. It is recorded so the service can be restored. Many bugs are found before they harm anyone, and an incident can come from configuration, capacity, or a dependency rather than from a flaw in the software. Linking them is optional and meaningful: the incident's related bug points at a bug when the harm comes from a software flaw. The attribute is absent when the cause is something else. The link does not make the incident a bug or the bug an incident.
Incident severity grades the impairment of the running service. It is a different attribute from bug severity. The same flaw can carry both once it hurts a service. Severity vs priority keeps the grade of the impairment separate from impact, urgency, and the queue. Incident vs problem vs change keeps the harm separate from the cause and from the proposal to remove it.
Technical debt can meet the specification
The four copies of the tax function may do exactly what the specification says. That technical debt item can be a shortcut, a workaround left in place, or a design that has aged. The software meets its requirements, so this is not a bug and not a defect. Nothing has to be failing now, so it is not an incident. It is still a work item, scheduled with a priority like any other.
Rewriting the four copies into one function is delivery work. It is not a postmortem, and it is not proof that an incident happened. If one of the copies is the flaw behind the double charge, that flaw is the bug. The other three copies can remain debt.
| Bug (defect is the same record) | Incident | Technical debt | |
|---|---|---|---|
| Invented Lantern case | Tax rounds down by one cent, found in test | Buyers charged twice for 16 minutes | Tax function pasted four times; tests pass |
| What is wrong | A flaw in the software | Harm to a running service | Later change is slower or riskier |
| Must someone be hurt now? | No | The record is the interruption | No |
| What you file | A work item to correct the flaw | A support ticket to restore the service | A work item for the shortcut or the aged design |
When a report counts "defects in production", say whether the rows are bugs found after release, incidents, or both joined together. The join is useful. The shared label is not. The cents, the sixteen minutes, and the four copies are made up.
