Software bug
A software bug is a flaw in a program's code, configuration or design that makes it behave differently from what was specified or reasonably expected. The bug is the flaw in the software itself; the crash, wrong total or blank screen a user sees is the failure it produces. A bug can sit in shipped code for years before any input reaches it.
The longer version
A bug enters a program when somebody writes something the program was not meant to do: an off-by-one in a loop, a date parsed in the wrong time zone, a stylesheet rule that hides a button on narrow screens. The code runs exactly as written, and the program does not know it is wrong. It becomes visibly wrong only when an input or a sequence of actions reaches the flawed line, and until then the bug is latent, present in the shipped code and unreported.
Three neighbouring words get used for the same thing. A defect is the formal name for the flaw, the word standards bodies and most trackers prefer; the two are interchangeable in daily use, and the distinction is covered under defect vs bug. A failure is the observable result, the moment the flaw produces wrong output. An issue is anything filed in a tracker, and an issue is often a request, a question or a misunderstanding rather than a bug at all; that pair is covered under issue vs bug.
The practical difficulty is that 'supposed to do' is often unwritten. A tester files a bug because the export button downloads a CSV with the columns in a different order from the on-screen table; the developer closes it as intended behaviour because no specification ever said the order mattered. Both are right, and the argument is about the spec, not the code. The second difficulty is that a bug is only fixable once it is reproducible, so a report that says what happened without saying on which page, in which browser, after which clicks, describes a failure without locating the bug.
A filed bug is classified three ways. Its kind, whether functional, visual, performance, security or data, decides who can fix it; its severity rates how much damage it does; its priority decides when it gets fixed. The kinds are covered under types of software bugs and the damage scale under severity levels.
Common questions
Why do developers close a bug as working as intended?
Because the behaviour in the report is what the software was built to do, and the disagreement is about the specification rather than the code. A CSV whose columns differ from the on-screen table is a bug if the order was specified and a request if it was not. The way out is to settle the expected behaviour in writing, then reopen the report as a bug or refile it as a change.
Is a bug always caused by bad code?
A bug is any gap between expected and actual behaviour, and the flaw can sit in configuration, in data, in a third-party dependency or in the specification itself. A feature built exactly as specified but specified wrongly is still a bug from the user's side, and the fix lands in the requirement before it lands in the code.
What should a bug report contain?
The page or screen where it happened, the steps that lead to it, what was expected, what happened instead, and the environment: browser, operating system, device and account state. A screenshot or recording shortens every later conversation. A report missing the steps is a failure sighting rather than a bug report, because nobody can find the flaw from it.
Where do software bugs come from?
From a gap between what somebody meant and what got written: a requirement read two ways, a case nobody thought of, a change that broke an assumption in code nobody reread, a library upgraded with different behaviour. Environments add their own: a query that runs fine on test data and times out on production volumes. Most bugs are ordinary mistakes reaching code that no test exercised, rather than anything exotic.
Who is responsible for fixing a software bug?
The developer who owns the code the flaw sits in, assigned at triage once the bug is confirmed and rated. The reporter's job ends with a reproducible report, and a tester or a second developer verifies the fix against the original steps before the ticket closes. A bug with no named owner is the one that waits, which is why triage assigns before it ranks.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.