What Is a Software Bug? Severity, Priority, and Why They Differ
A software bug is a defect causing behaviour to differ from the requirement. Six categories, how severity and priority come apart, and why mobile bugs resist reproduction.
Yuvan Sundrani · 16 min read
autosana.ai
TL;DR
- A software bug is a defect in code, data, or configuration making the system behave differently from its requirement.
- Error, defect, and failure describe three different things. Many defects produce zero failures because the path stays untaken.
- Severity measures technical impact and priority measures business urgency. They are set by different people and routinely disagree, which is the point.
- A software bug costs more at every stage it survives, so the escape point is worth recording alongside the fix.
A crash affecting 0.3 percent of sessions is severity critical and priority low. A misspelled company name on the signup screen is severity trivial and priority urgent, because the CEO saw it.
Both calls are correct. Severity and priority measure different things, and a triage process collapsing them into one number produces arguments that look technical while being about who decides.
This guide covers what qualifies as a software bug, where bugs originate, the six categories worth sorting into, how severity and priority come apart, and what makes a report reproducible on mobile.
What Counts as a Software Bug?
A software bug is a defect causing the system to behave differently from its specified requirement. The ISTQB Foundation Level syllabus separates three terms that get used interchangeably and should stay distinct.
| Term | What it is | Where it lives |
|---|---|---|
| Error | The human mistake | In the person |
| Defect | The resulting flaw | In code, data, or configuration |
| Failure | What the user experiences | At runtime, when the path executes |
ISO/IEC/IEEE 29119-1 uses the same separation. It matters practically: a defect found by code review has produced zero failures, while one reported from production has produced many. Both may need the identical code change though the urgency differs completely.
One more distinction. Where behaviour differs from the requirement, it is a software bug. Where it differs from an expectation the requirement left unrecorded, it is a requirement gap wearing a bug report. Both deserve fixing, though only one is a coding problem.
Where Do Software Bugs Come From?
Classifying by origin changes what you do about them, since each source has a different prevention.
| Origin | Example | Prevention |
|---|---|---|
| Requirement | Threshold left ambiguous, built wrong | Acceptance criteria with numbers |
| Design | Component depending on wall-clock time | Testability review before implementation |
| Code | Off-by-one, wrong comparison operator | Unit tests, code review |
| Configuration | Staging key shipped in a release build | Environment-scoped config, build assertions |
| Data | Legacy rows violating a new constraint | Migration testing against production-shaped data |
| Environment | Works on one OS version, fails on another | Device matrix coverage |
Recording origin alongside each defect takes a dropdown field and tells you where to invest. A team finding half its escapes originate in requirements has a writing problem rather than a testing problem, and more test cases will fix zero of it.
What Are the Six Categories of Software Bug?
What Is a Functional Bug?
The feature produces a wrong result. A discount applied at the wrong threshold, a search returning stale results, an order total miscalculated. These are what regression testing is built to catch, and a smoke test catches the subset severe enough to block a build.
What Is a UI or Layout Bug?
The feature works while the interface misrepresents it. Content clipped at a narrow viewport, a button pushed below the fold, a label overlapping an icon at large text settings.
Mobile produces these disproportionately, since one layout renders across dozens of screen geometries and font scale settings.
When Does Slowness Count as a Software Bug?
When correct output arrives too slowly to be usable. An eleven-second checkout is functionally perfect and commercially broken. Performance testing targets this class, and the threshold belongs in the requirement rather than in somebody's judgement.
What Is a Compatibility Bug?
The feature works on some configurations and fails on others. A gesture handled differently under a vendor OS skin, a WebView version rendering a form incorrectly, an API deprecated in a newer release.
What Makes a Defect a Security Bug?
Data exposed, access granted incorrectly, or input accepted that should be rejected. Mobile app security testing covers the discipline, and these carry consequences beyond the product.
Is a Usability Problem a Software Bug?
It works, runs fast, renders correctly, and still defeats the user. An error message naming an internal code rather than the problem. A destructive action lacking confirmation.
This category attracts the most triage argument, since reasonable people disagree about whether it counts. Writing the requirement in advance settles it.
Martin Fowler's test pyramid is a useful lens on where each category gets caught: a functional software bug is cheap to find at the unit layer, while compatibility and usability defects surface only higher up.
What Is the Difference Between Severity and Priority?
| Term | Definition | Set by | Changes |
|---|---|---|---|
| Severity | Technical impact if it executes | QA or engineering | Rarely, once assessed |
| Priority | Business urgency of fixing it | Product owner | Often, as context shifts |
Every software bug lands in one of four combinations.
High severity, high priority: checkout fails for every user on the current iOS version. This one gets fixed the same day.
High severity, low priority: data corruption in a feature used by eleven accounts on an OS version being dropped next quarter. Serious if it runs, and the business can wait.
Low severity, high priority: a typo in the company name on signup. Trivial technically, urgent commercially.
Low severity, low priority: an icon misaligned by two pixels on one tablet in landscape. Backlog.
Rows two and three are where triage earns its keep. Teams recording a single combined number lose the ability to express them, and a dangerous software bug gets deferred while trivia gets fixed.
Why Does a Software Bug Cost More the Longer It Survives?
The cost of a defect rises at each stage it passes through, and the multiplier comes from how many people become involved.
A defect caught at code review costs one person a few minutes. The same defect caught in CI costs a context switch and a pipeline run. Caught in QA, it costs a report, a triage decision, a fix, and a retest across a device matrix. Reaching production, it costs all of that plus support contacts, and on mobile it waits for a store review before reaching anybody.
That final step is what makes mobile distinct. A backend fix deploys within the hour while a mobile fix needs a build, a review, and then users choosing to update.
Record the escape point for each production defect: the earliest stage that could have caught it. The pattern across twenty defects names which stage leaks, and that is actionable in a way a bare defect count fails to be. Shift-left testing is the response once you know where the leak sits.
How Do You Write a Bug Report Someone Can Act On?
A software bug gets fixed quickly when the report removes guesswork. Seven fields do most of the work.
| Field | What it must contain |
|---|---|
| Title | Observed behaviour, rather than a theory of the cause |
| Environment | Build number, OS version, device model, backend target |
| Steps | Followable by a stranger, with real data values |
| Expected and actual | Stated separately, since merging hides which is disputed |
| Frequency | Every attempt, or one in ten |
| Evidence | Video or screenshots plus logs |
| Severity and priority | Separate fields, assigned by their respective owners |
Our issues records carry these fields, and notifications route a new report to whoever owns the area.
The field most often missing is frequency. An intermittent defect needs a different investigation from a deterministic one, and a report omitting it sends a developer looking for a reproduction that occurs one time in ten.
Why Do Mobile Bugs Resist Reproduction?
Four properties make a mobile software bug harder to find and harder to reproduce.
Device fragmentation means a defect may exist on one manufacturer's OS fork alone. A report lacking the device model is frequently unreproducible for that reason by itself.
State persists across sessions. A defect appearing only after a specific sequence of backgrounding, cache state, and permission responses resists a clean reproduction.
Connectivity varies. A transaction interrupted mid-flight produces a defect class with no desktop equivalent, and reproducing it requires controlling the network rather than the app.
Users update when they choose. A defect fixed three releases ago still generates reports from people on old builds, so triage must separate those from genuine regressions.
Testing a mobile app across a real device matrix converts these from production surprises into pipeline failures, and real device testing covers the vendor and hardware cases emulators skip.
How Autosana Fits
We make a software bug arrive already documented.
Every run records video and step-level results per device. When a flow fails, the report carries device model, OS version, build, the exact failing step, and a replay of what preceded it.
That removes the most common reason reports stall, which is a reproduction working for the reporter and failing for everybody else.
We run suites across real hardware through real device testing, so compatibility defects surface against the vendor forks your users run rather than a stock emulator image.
Failures link to issues and route through notifications to the owning team, keeping the gap between detection and triage short.
Conclusion
Open your last twenty closed software bug reports and check how many recorded severity and priority as separate fields.
Where they were merged into one number, look at what got deferred. The pattern worth finding is a high-severity software bug sitting in the backlog because its business urgency was low and the single field could carry only one of those facts.
Then check how many reports named a device model. On mobile that one field decides whether a report is reproducible at all.
.png)
FAQ
What is a software bug?
A software bug is a defect in code, data, or configuration causing the system to behave differently from its specified requirement. It exists regardless of whether anyone has executed that path.
What is the difference between an error, a defect, and a failure?
An error is the human mistake. A defect is the resulting flaw in code. A failure is what a user experiences when that defect executes. Many defects produce zero failures.
Where do software bugs originate?
Requirements, design, code, configuration, data, and environment. Recording origin per defect tells you where to invest, since a team whose escapes trace to requirements has a writing problem.
What is the difference between severity and priority?
Severity measures technical impact and is assessed by QA or engineering. Priority measures business urgency and is set by the product owner. They are deliberately separate and often disagree.
Can a bug be high severity and low priority?
Yes. Data corruption in a feature used by eleven accounts on an OS version being dropped next quarter is serious if it executes and still reasonable to defer.
Why does a defect cost more the longer it survives?
Each stage involves more people. Code review costs minutes, QA costs a report plus triage plus retest across a matrix, and production adds support contacts plus a store review before any fix reaches users.
What belongs in a bug report?
Observed behaviour as the title, full environment including device and build, reproducible steps with real values, expected and actual stated separately, frequency, evidence, and severity and priority as distinct fields.
Why are mobile bugs harder to reproduce?
Device fragmentation, state persisting across sessions, varying connectivity interrupting transactions, and users running builds from several releases back. A report missing the device model is often unreproducible.