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.

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.

Understanding this difference shows that you are thinking not just as someone who "found a problem," but as someone who cares about the product and the business.

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.

What to learn next. Now that you understand what a bug is and how to assess its importance, the next most important skill is how to write a bug report so that a developer can reproduce and fix it.