What Is a Bug Report? Anatomy, Examples, and a Free Template

You will also see the formal term defect report. The ISTQB glossary defines it as a structured record of a defect, and lists the canonical fields: an ID, a summary, steps to reproduce, expected versus actual result, severity, priority, environment, and attachments. ISTQB also draws a line you should keep in mind — a defect is not the same as an incident. An incident is any event during testing that needs investigating, and only some incidents turn out to be real defects. Triage is the step that promotes an incident into a confirmed bug.

The whole point of a bug report is reproduction. Google's web.dev guide to filing a good browser bug puts it plainly: a minimal, reproducible test case is the single biggest factor in whether a bug gets fixed. It lists the core components you need — a clear description, steps to reproduce, the expected result, the actual result, a minimized test case, and environment details such as OS, display DPI, and browser version. Mozilla's bug writing guidelines say the same in different words: precise steps, an explicit expected-versus-actual pair, and the environment it happened in.

There is hard evidence for which fields matter most. In the most-cited study on the subject, Bettenburg et al. (FSE 2008) surveyed 466 developers and reporters across the Apache, Eclipse, and Mozilla projects. They found a structural mismatch: developers rank steps to reproduce, stack traces, and test cases as the most useful contents of a report — yet those are precisely the items reporters find hardest to supply. The same paper built a prototype quality tool, CUEZILLA, trained on 289 manually rated reports, that predicted report quality with 31–48% accuracy. The takeaway is that report quality is measurable, structured, and dominated by two fields most people skip when they are in a hurry.

Here is where the Bettenburg mismatch becomes a product decision. The fields developers value most are the ones reporters struggle to write — so the right move is to capture those fields automatically rather than ask a human to type them. When you grab a bug with the BugMojo browser extension, the environment row reads itself from the browser and page (OS, browser version, URL, viewport). The actual result is backed by an rrweb session replay plus the console logs and network requests captured at the instant of failure, so the stack trace and the failing POST /api/cart are attached without anyone copying them. What is left for the human is exactly the part a machine cannot infer: a clear title, the expected result, and a severity. For the field-by-field craft of writing those well, see the guide on how to file a bug report.

The second shift is who reads the report. Most bug formats are prose written for people, which means an AI agent has to guess where the fields are. Teams that adopt structure tend to enforce it at the platform level — GitHub issue forms let maintainers 'customize and standardize the information you'd like contributors to include' through typed, required fields. BugMojo takes the same typed anatomy and exposes it over an MCP server, so an agent like Claude Code or Cursor reads the title, steps, expected-versus-actual, environment, console, network, and replay as structured context. That matters more every year: in the 2024 Stack Overflow Developer Survey, 62% of developers reported using AI tools in their workflow (up from 44%) and 76% are using or planning to. Bug context now has to be readable by machines, not just humans.