A bug report is a structured record describing a software defect: what the user did, what the software was expected to do, what it actually did, and in which environment. In software quality work, it is the primary handoff between people who find problems and people who fix them, and its quality largely determines how quickly a defect is resolved.
Bug reports are filed by testers, developers, support staff and end users, usually in an issue tracker where each report receives an identifier, a status and an owner. Unlike an automatically generated crash report, a bug report is written by a person and can describe wrong behavior that never crashes anything, such as an incorrect total on an invoice.
Anatomy of an effective bug report
A good bug report lets a developer who has never seen the problem reproduce it on the first attempt. Most teams use a template with fixed fields, because a missing environment detail or vague step can cost hours of back-and-forth.
| Field | What it contains | Why it matters |
|---|---|---|
| Title | Symptom plus location in one line | Enables search and duplicate detection |
| Steps to reproduce | Numbered, minimal actions from a known state | Lets anyone trigger the defect |
| Expected result | What should have happened | Defines the correct behavior |
| Actual result | What happened instead, with exact messages | Shows the deviation precisely |
| Environment | Version, build, OS, browser, device, configuration | Many defects occur only in one setup |
| Evidence | Screenshots, logs, recordings, sample files | Removes ambiguity from the description |
| Frequency | Always, intermittent, or once, with a rate | Guides how to investigate |
The single most valuable field is steps to reproduce. Steps should start from a defined state (for example, a fresh login with a test account), contain one action per line, and be reduced to the shortest sequence that still triggers the defect. A report that says only “export does not work” forces the developer to guess the file type, data size and screen involved.
Severity, priority and triage
Once filed, a report enters triage, where a team confirms it, removes duplicates and decides when it will be fixed. Two separate ratings drive that decision: severity describes technical impact, while priority describes business urgency.
| Severity | Definition | Example |
|---|---|---|
| Critical | Data loss, security breach or total outage | Payments are charged twice |
| Major | Core function broken, no reasonable workaround | Users cannot save documents |
| Minor | Function impaired, workaround exists | Sorting ignores accented letters |
| Trivial | Cosmetic issue with no functional effect | Misaligned icon in a settings dialog |
The two ratings often diverge. A typo in the company name on the login page is trivial in severity but high in priority, while a crash in a rarely used legacy import may be major in severity but low in priority. Keeping the two fields separate prevents teams from confusing loud problems with important ones.
The life cycle of a bug report
A bug report moves through a defined workflow so that everyone can see who owns it and what happens next. Exact status names vary between trackers, but the stages are consistent.
| State | Meaning | Who acts next |
|---|---|---|
| New | Filed, not yet reviewed | Triage team |
| Confirmed | Reproduced and accepted as a defect | Product owner sets priority |
| In progress | A developer is fixing it | Assigned developer |
| Resolved | Fix merged into a build | Tester verifies the fix |
| Closed | Fix verified or report rejected | No further action |
| Reopened | Fix failed or defect returned | Assigned developer |
Reports can also be closed with a resolution reason instead of a fix: duplicate, cannot reproduce, works as designed, or will not fix. A high share of cannot reproduce closures usually signals weak reporting templates rather than unreliable testers. When a fixed defect returns after a later change, it is tracked as a regression and often linked to the original report.
Bug reports compared with related records
Several quality artifacts describe problems, but they differ in who creates them and how much context they carry.
| Record | Created by | Main content | Limitation |
|---|---|---|---|
| Bug report | A person | Steps, expectation, observed behavior | Depends on reporter skill |
| Crash report | Software automatically | Stack trace, memory state, module versions | No user intent or steps |
| Telemetry | Software automatically | Aggregated usage and error metrics | Shows trends, not individual causes |
| Feature request | A person | Desired new behavior | Not a defect; handled as planning |
| Support ticket | A customer or agent | User problem in business terms | May hide several defects or none |
Mature teams link these records together: a support ticket spawns a bug report, which references matching crash reports and telemetry counts that show how many users are affected.
Common mistakes in bug reporting
Most delays in fixing defects come from avoidable reporting errors, not from technical difficulty.
- Several defects in one report, which makes the report impossible to close cleanly.
- Interpretation instead of observation, such as “the database is broken” rather than the exact error text.
- Missing version or build number, so developers test against code that already differs.
- Sensitive data in attachments, such as real customer records or passwords in screenshots; redact before uploading.
- Emotional or blaming language, which slows triage and adds no technical information.
Before filing, reporters should search for existing reports and add new evidence to a matching one. Duplicates split the discussion and hide how many users a defect really affects.
Understanding it simply
A bug report is a note for software developers. It says exactly what went wrong and how to make it happen again. Think of a good description for a car mechanic. “The car shakes when braking at 100 km/h” helps far more than “the car feels strange”.
The developer must see the problem before fixing it. Clear steps help. So do the expected result, the actual result and a screenshot. Together they turn a vague complaint into a problem that can be solved in hours instead of weeks.
Applied in practice
A tester on a web shop team notices that some orders show a wrong VAT total. Her first impression is that “tax calculation is broken”, but she narrows it down before filing: the error appears only when a discount code is combined with free shipping, and only in version 5.12.0.
Her report lists six numbered steps from an empty cart, the expected VAT of 20.00 EUR on a 100.00 EUR net order, the actual VAT of 21.50 EUR, the browser and build number, and a screenshot of the order summary. The steps show that tax was charged on the waived shipping fee of 7.50 EUR, which accounts for exactly the extra 1.50 EUR.
The developer reproduces the defect in ten minutes, finds that shipping was removed after tax had already been calculated, and ships a fix the same day. The tester verifies it, adds the scenario to the automated regression suite, and closes the report.