← back to the section

A bug (also called a defect) is a mismatch between how the program actually works and how it is supposed to work. The key word is "supposed to": to call something a bug, you need to know what the correct behavior should be. If the behavior seems odd but matches what the requirements describe, it is not a bug.

Finding a bug is half the job. The other half is correctly assessing how important it is — because you can't fix everything at once, and the team needs to know what to tackle first. There are two separate scales for this: severity and priority.

one observation, three verdicts — the baseline decides cart holds 3 items counter shows 2 what should it be? requirement: counter = items requirement: counter = lines no requirement for this screen bug not a bug ask firstnot a defect verdict is «bug» — now two independent ratings severity priority: low priority: high critical minor waits in queue rare config fix right now payment down maybe never misaligned icon fix today company name waits in queuerare configfix todaycompany nameseverity ≠ prioritybreaks badly isnot the same asneeds fixing nowthe diagonal cases

At the top, one and the same observation: the counter disagrees with the number of items. The verdict comes not from the observation but from the baseline — one requirement makes it a bug, another declares it by design, and silence in the requirements turns it into a question for the analyst. Below are the two independent ratings of a bug already filed: the diagonal holds exactly the cases where severity and priority disagree.

What counts as a bug

A bug is a deviation from expected behavior. That expectation comes from requirements, mockups, common sense, and general rules (for example, "the application must not crash" is always a bug, even if it's never written down explicitly).

Common doubts for beginners:

  • "It's strange, but it's in the requirements." Not a bug. If you think the requirement is bad, that's a conversation with the analyst — not a defect.
  • "The requirements say nothing about this." Possibly a bug: there are unspoken expectations (don't crash, don't lose data, show clear error messages). Cases like these are worth discussing with the team.
  • "I don't like how it looks." Not a bug on its own if it matches the mockup. But if it's genuinely inconvenient or unreadable, it's worth logging as a usability note.

When you're unsure whether something is a bug, don't stay silent — ask. "Is this by design, or is it a bug?" is a perfectly normal question to raise.

Error, defect, failure: where bugs come from

In strict terminology, the word "bug" hides a chain of three links:

  • Error — a human action: a developer made a typo, an analyst wrote an ambiguous requirement.
  • Defect (bug) — the result of that error in the product: a wrong line of code, an incorrect condition. A defect can sit quietly in the code without ever showing itself.
  • Failure — the defect manifesting at runtime: the program crashed, calculated wrongly, displayed the wrong thing.

What the tester notices is failures — but what the report describes is the defect, dug down to its cause. An important consequence: defects live not only in code — also in requirements, documentation, and settings. An ambiguous requirement is just as much a defect, and it is cheapest to catch before any code is written.

In everyday speech all of this is called "a bug," and that's fine. But understanding the chain helps you report the essence: not "something crashed somewhere" (the failure), but what exactly works incorrectly (the defect).

Severity — how badly it breaks things

Severity answers the question: how badly does the bug damage the product technically when encountered? It is an objective characteristic of the defect itself. Common levels:

  • Blocker. Nothing can proceed: the application won't open, payment doesn't go through at all.
  • Critical. An important feature breaks or data is lost: orders won't be created, money is charged incorrectly.
  • Major. A noticeable feature works incorrectly, but there is a workaround.
  • Minor. A small issue: a misaligned button, a typo, an ugly but understandable error message.

Severity is usually assigned by the tester — they are the one who sees what broke and how.

Priority — how urgently it needs to be fixed

Priority answers a different question: how urgently does this need to be fixed from a business perspective? Typical values: High / Medium / Low. Priority is usually decided by the manager or the team — not by the tester alone — because it is about business, not just the technical issue.

The key idea: severity and priority are two different things, and they do not always match. Classic examples:

  • High severity, low priority. The application crashes, but only under an exotic configuration that almost no one uses. Serious in nature, but not urgent to fix.
  • Low severity, high priority. A typo in the company name on the homepage, or an incorrect logo. Technically trivial (minor), but embarrassing and visible to everyone — it needs to be fixed immediately.

Where this applies

You assign severity and priority to every bug you log — it is part of the bug report. This determines whether the bug gets picked up now or put aside. Get the assessment wrong, and the team either wastes effort on something trivial or misses something important. That is why severity and priority are not a formality — they are how you communicate to the team how bad the situation is and how soon it needs attention.

Where beginners stumble:

  • They confuse severity and priority, or treat them as the same thing. These are two different scales: "how badly it breaks" and "how urgently it needs to be fixed."
  • They mark everything as "critical." If everything is critical, nothing is. Assess honestly — otherwise people stop trusting your ratings.
  • They log as a bug something that is intentional, without checking the requirements first. Always ask "is this the intended behavior?" before filing.

In short

  • A bug is a mismatch with how things are supposed to be; without a baseline (requirement, mockup, common sense) there is no verdict.
  • The chain: a human error → a defect in the product → a failure at runtime. You notice failures, you report defects.
  • Defects are not only in code: an ambiguous requirement is just as much a defect, and the cheapest one to fix.
  • Severity is set by the tester and is about the technical damage; priority is set by the team and is about the business.
  • The scales diverge: a crash under a rare config is high severity and low priority; a typo in the company name is the opposite.