Types of software bugs

The longer version

Classifying by type answers a different question from severity and priority. Those two rank a defect against everything else the team could be doing; the type says which part of the system is misbehaving, which is what decides who picks the report up and what evidence would settle it. No standards body publishes the list, and the categories overlap by construction, so the useful test for a taxonomy is whether it routes a report to the right person, not whether it is exhaustive.

Four families describe what somebody meets on screen. A functional bug is behaviour that contradicts the requirement: the button saves the wrong record, the filter returns rows it should exclude, the export omits a column. A user interface bug is behaviour that is technically correct and still wrong to look at or unusable: text clipped at a narrow viewport, a control overlapping another, a state that renders with no visible focus. A performance bug is behaviour that is correct but too slow or too expensive to be worth using: a list that takes seconds to paint, a memory footprint that grows until the tab dies. A compatibility bug is behaviour that is correct in one environment and broken in another, most often a different browser, operating system, screen size or an older version of any of them.

Four more describe the cause rather than the symptom. A logic bug is code that runs without error and computes the wrong answer: an off-by-one boundary, an inverted condition, a rounding rule applied to the wrong currency. A data bug lives in what is stored or transformed rather than in the code path: a record saved in the wrong encoding, a migration that dropped a relation, a timestamp written without its time zone. An integration bug appears where two systems meet and neither is wrong on its own: a contract changed on one side of an API, a webhook delivered twice, a queue whose consumer assumes an order the producer never promised. A security bug is behaviour that lets somebody do something they are not entitled to: an endpoint that trusts a parameter, a session that survives a sign-out, a file served without checking who asked for it.

A real report often fits two families at once, and the label it is filed under is usually the one that names the symptom rather than the cause. A checkout that fails on one browser is filed as a compatibility bug until somebody finds the date parsing behind it and it becomes a logic bug. A page that loads slowly is filed as a performance bug until the profile shows a single query returning far more rows than it should. Types are assigned at triage from the evidence available at that moment, so a taxonomy is worth keeping loose enough that relabelling a report is routine rather than an admission that the first pass was wrong.