What a bug ticket owes a developer

A bad bug ticket is not a small problem. It is a developer opening a task, failing to reproduce it, asking a question in a thread, waiting a day for the answer, and then discovering the issue was already fixed. That is an afternoon, and it happens to some percentage of every ticket queue.

The fix is boring: decide what a ticket must contain, and don't file one without it.

The six fields

1. What you did. The exact steps, in order, from a known starting state. "Logged in as an existing user, opened /settings/billing, clicked Change plan."
2. What happened. The observed result, quoted where possible. Error text goes in verbatim, not paraphrased.
3. What you expected. Obvious to you, not to the reader. This is also the field that catches the reports that turn out to be a misunderstanding rather than a defect.
4. Where. Browser, version, device, environment, and the build or commit. staging @ a3f19c2 is a sentence; "on staging" is not.
5. How often. Every time, one time in five, or once and never again. A developer triages an intermittent bug completely differently, and needs to know before they start.
6. Evidence. A screenshot, a recording, a HAR file, the console output. Whatever you had open when it happened.

That is the whole list. It fits in a template, and it takes about ninety seconds once it is a habit.

Severity is not a feeling

The other thing a ticket owes is an honest severity, and the only way to keep that honest is to define the levels in terms of the user, not the reporter's frustration.

• Blocker: a core flow cannot be completed at all, and there is no workaround.
• Major: a core flow is degraded, or a secondary flow is broken. There is a workaround, and it is bad.
• Minor: visible, wrong, and survivable. Layout, copy, a slow path.
• Trivial: nobody outside the team will notice this quarter.

Two rules keep the scale useful. Severity describes impact, and priority describes when it gets fixed. They are different columns and they are allowed to disagree. And whoever files the ticket does not get the last word on either; the person who owns the release does.

The title is a search query

Six months from now someone will be looking for this ticket, and they will not remember what it was called. Write the title as the thing they will type.

Bad: Billing page broken

Good: Change plan button does nothing for annual subscribers on Safari

The second one names the component, the action, the affected segment and the platform. It is findable, and it is triageable from the queue without opening it.

Why this is a QA job

Developers write bad bug reports for the same reason they write incomplete tests: they already know the context, so the missing fields don't feel missing. Someone whose job is the report writes a better one, every time, and files it in a shape the team already agreed on.

Our reporting cadence covers what lands where and how often. The ticket format above is the part that matters most, and it is worth adopting whether or not you ever hire anyone to do it.