What Most Bug Reports Are Missing (15 Years of Research)

Here is one of the most reliable findings in all of software engineering research, and almost nobody acts on it: we have known for more than 15 years exactly what makes a bug report useful, and exactly what reporters leave out — and they are the same thing. The single most valuable element of a bug report is also the one most often missing.

This isn't opinion or a vendor talking point. It comes from peer-reviewed studies of hundreds of developers and thousands of real bug reports across Mozilla, Eclipse, and Apache. Below is what that research actually says, why the gap has survived every process change we've thrown at it, and the one approach that closes it.

Sit with that finding for a second. The two things developers most need are the two things reporters find hardest to give. That's not a discipline problem you can fix with a sternly worded template — it's a structural mismatch between what a person remembers after hitting a bug and what an engineer needs to recreate it.

Later work made the gap concrete. A 2020 study in Empirical Software Engineering analyzing real bug reports found that the elements reporters most often omit are precisely the high-value ones: steps to reproduce, a test case, a code example, the stack trace, and the expected behavior. The importance ranking and the omission ranking are almost the same list, in the same order.

The downstream cost of the mismatch has a name every engineer knows: Works For Me. Research characterizing non-reproducible bug reports found they commonly fail for a small set of reasons — missing or imprecise steps, an unknown environment, or the specific data that triggered the bug. When those are absent, the engineer isn't debugging; they're guessing at the state the reporter was in.

And a separate study assessing the quality of reproduction steps found that better steps correlate with faster resolution. The chain is direct: vague repro → can't reproduce → the ticket bounces back and forth or gets closed as "Works For Me" → the bug ships anyway. The missing information at the top of the funnel becomes wasted engineering time at the bottom.

You might expect AI coding assistants to make report quality irrelevant. The 2025 Stack Overflow Developer Survey suggests the opposite. Its top developer frustration — cited by 66% — was "AI solutions that are almost right, but not quite," and 45% said debugging AI-generated code is more time-consuming. An AI agent, exactly like a human, needs to know what actually happened to produce a correct fix. Feed it a one-line ticket and it produces an "almost right" guess. Feed it a real reproduction and it has something to reason about.

Pulling the studies together, these are the high-value elements that go missing most often — in rough order of the pain they cause:

1. Steps to reproduce. The single most valuable element, and the hardest to write from memory after the fact.
2. Expected vs actual behavior. Without both, the engineer can't tell what "fixed" even means.
3. The stack trace or console error. Rated near the top for usefulness; usually never copied in.
4. Environment. Browser, OS, screen size, URL, build — the variables that make a bug appear for one person and not another.
5. The triggering data or state. The specific account, input, or feature flag that the bug depends on.

Notice what these have in common: they all describe what actually happened in the session. A human reconstructs them imperfectly from memory. A recording of the session has them all, exactly, for free.

There are two honest ways to fix the mismatch, and they stack:

1. A real template. Give reporters a structure that prompts for steps, expected vs actual, and environment. This helps — a good bug report template raises the floor. But it still depends on the reporter remembering and typing accurately, which is exactly the effort the research says people struggle with.

2. Capture the session automatically. The researchers themselves pointed at missing tooling as the root cause. A capture tool records what happened rather than asking the reporter to recall it: an rrweb DOM replay (the real, inspectable DOM, not a video), the console log, the network waterfall, and the environment — attached to the report automatically. Every one of the five most-missing elements is present because it was recorded, not remembered.

That's the whole idea behind BugMojo: one click captures the reproduction, so the report is complete by construction and can be handed to an AI agent over MCP. It doesn't ask reporters to be more diligent; it removes the step where diligence was required.

It's worth naming the reflex this research should kill: blaming the reporter. When a ticket arrives with no repro, the instinct is to write a stricter template, add required fields, or run a training session on "how to file a good bug." Those help at the margin, but the studies are pointing somewhere else. The reporters aren't lazy — they're being asked to reconstruct, from memory and after the fact, precisely the information that is hardest for a human to reconstruct: exact steps, exact environment, the console output they never saw. The mismatch is baked into the task, not the person.

That reframing is freeing, because it means you can engineer the problem away instead of exhorting people to try harder. Anything that records the session at the moment the bug happens — rather than asking someone to remember it later — converts the five most-missing elements from "hopefully the reporter included them" into "present by default." The best bug report is one nobody had to write carefully, because the important parts were captured, not recalled.