A software bug is a defect that makes a program behave incorrectly or fail to meet its intended requirements. The visible symptom might be a crash, an incorrect calculation, a missing result, or a feature that works in one environment but fails in another.
For customer support, the important first step is to describe the gap between the expected result and what actually happened. You do not need to identify the faulty code before reporting the problem.
Software bug examples at a glance
| Type | Example symptom | Useful evidence |
|---|---|---|
| Functional | Selecting Save does not save a valid form. | Steps, field values, and the result after reopening the record. |
| Performance | A search takes much longer under a particular workload. | Measured duration, workload, environment, and comparison conditions. |
| Compatibility | A control works in one browser but fails in another. | Browser and OS versions plus the same reproduction steps. |
| Usability | An error message prevents the user from understanding how to continue. | The message, intended task, and point where the user becomes stuck. |
| Security | An account can access a resource it should not be allowed to see. | A private report through the vendor’s security channel. |
These are illustrative categories, not a universal classification system. One defect can produce several symptoms. For example, a compatibility issue can also cause a functional failure.
Bug, error, and failure: what is the difference?
Teams sometimes use these terms interchangeably, so agree on the meaning in your own workflow. A useful distinction is that a defect is the underlying problem, while a failure is the incorrect behavior observed when the software runs. An error message is information the application displays; it does not by itself prove a defect.
For example, “Your password is incorrect” may be an expected response to an invalid password. A valid password being rejected under reproducible conditions may indicate a bug, but support still needs to check account status, authentication settings, and other relevant conditions.
Describe observations separately from guesses. “The page returned a 500 response after I selected Export” is a fact you can investigate. “The database is broken” is a proposed cause that may be wrong.
Why software bugs happen
Defects can arise in requirements, design, implementation, integration, or configuration. They are not limited to typing mistakes in code. A team might misunderstand how a rule should work, overlook an edge case, or make assumptions about data that do not hold in production.
- Unclear requirements: two teams interpret the expected behavior differently.
- Logic mistakes: a calculation or condition handles an input incorrectly.
- Integration assumptions: a service returns data in a shape the application does not handle.
- State and timing: a problem appears only when actions happen in a particular order.
- Environment differences: permissions, browser behavior, or configuration differ from the conditions tested.
- Changes to existing behavior: an update breaks a workflow that previously worked.
The last case is commonly called a regression. Record when the workflow last worked and which version or change first showed the problem, if you know. Do not assume that a recent release caused the issue solely because the timing is close.
How to tell whether a problem is a bug
Start with the intended behavior and the conditions needed for it. Check the relevant instructions, account permissions, and input requirements. Then try the smallest set of steps that reproduces the problem.
- State the task: what were you trying to accomplish?
- Identify the expected result: what should happen under these conditions?
- Record the actual result: what appeared, changed, or failed?
- Check the scope: does it affect one user, one browser, one record, or several?
- Record repeatability: does it happen every time, occasionally, or only once?
A connection failure, missing permission, or unsupported input may explain the symptom without a software defect. If you are unsure, report the observed problem and the checks you performed. Avoid repeatedly testing actions that could charge money, delete data, or affect other users.
How to report a software bug
A useful report lets another person investigate without reconstructing the entire conversation. Include a precise summary, the environment, reproduction steps, and separate expected and actual results. This approach is consistent with Mozilla’s bug-writing guidance.
Title: [Specific action and observed failure] Environment: [Product version, browser, OS, and relevant role] Starting state: [Setup needed before the steps] Steps to reproduce: 1. [First action] 2. [Next action] 3. [Action that reveals the problem] Expected result: [What should happen] Actual result: [What happened instead] Frequency: [Every time, intermittent, or observed once] Impact: [Who is blocked and what they cannot do] Evidence: [Relevant screenshot, recording, or error message] Already tried: [Checks or workarounds and their results]
Use our bug report templates for different handoff formats, or see filled bug report examples for complete reports.
A short screen recording can show the sequence and visible failure. Written steps remain useful for searching, triage, and reproduction. Use sample data where possible and remove credentials or private customer information from evidence. Report suspected security vulnerabilities through a private security channel.
How teams find and fix bugs
Teams find defects through testing, customer reports, monitoring, and investigation. The process usually includes triage, reproduction, diagnosis, a change, and verification.
- Triage: clarify the impact, scope, and urgency; identify the owner.
- Reproduce: establish the conditions that trigger the behavior.
- Diagnose: investigate the cause using appropriate evidence.
- Fix: change the code, configuration, or requirement responsible.
- Verify: confirm the reported case works and check relevant neighboring behavior.
- Communicate: explain the result and any remaining limitations to affected users.
Severity describes the impact of a problem; priority describes when the team plans to address it. A visual defect on a critical customer workflow may receive attention before a more severe issue in an unused feature. Record the business context rather than trying to set urgency with dramatic language.
Reducing bugs before release
Clear requirements, code review, suitable tests, and realistic release checks can reduce defects. Review normal workflows as well as invalid inputs, permissions, interrupted operations, and changes to existing behavior.
Testing cannot establish that all possible defects are absent. Focus on the risks and conditions relevant to the product, and use production feedback to improve future checks. For support teams, consistent reports help turn customer symptoms into evidence engineering can act on.
Frequently asked questions
Is every error message a software bug?
No. Some messages are expected responses to invalid input, missing access, or unavailable services. Compare the result with the intended behavior and record the conditions before deciding.
What is a regression bug?
A regression is a defect in behavior that previously worked. Version information, the last known working case, and reproduction steps help a team investigate the change.
Can a bug be intermittent?
Yes. A problem may depend on timing, data, workload, or environment. Record when it occurred and how often, and preserve relevant evidence without claiming a cause you have not verified.
Do I need technical knowledge to report a bug?
No. Explain the task, steps, expected result, actual result, and impact in plain language. A clear description is useful even when you cannot diagnose the underlying defect.
