A bug report template for game QA — copy it, and know why each field exists

If you came here for a bug report template, copy the one below and go. But this post doesn't stop at the form. It also covers why each field exists — because a field nobody understands is a field that ends up empty, and empty fields are what get tickets closed as "cannot reproduce."

The template

## Title
[Scene/Feature] One-line summary (e.g. [Inventory] UI breaks when dragging an equipped item while full)

## Environment
- Build number:
- Platform / OS version:
- Graphics API / resolution / quality preset:
- Server / active live-ops events:

## Steps to reproduce
1.
2.
3.
- Reproduction rate: (e.g. 3 out of 5 attempts)

## Expected / Actual
- Expected:
- Actual:

## What happened right before
What you were doing in the 30–60 seconds before noticing the bug.
(Claiming a quest reward, a scene transition, a network drop — things that never make it into "steps")

## Attachments
- [ ] Video or screenshot of the moment
- [ ] Log file
- [ ] Game state (scene, items, progress)

## Severity / Frequency
- Severity: (blocker / broken feature / visual)
- Frequency: (always / often / sometimes / once)

Why each field is there

Reproduction usually fails for one of three reasons — lost conditions, timing, or environment drift. (Covered in detail in an earlier post.) The template's fields map onto those three, one by one.

"What happened right before" is the most important field in this template. Steps-to-reproduce only contain what the reporter recognized as a condition. The real cause — the inventory was full, a quest reward had just landed — lived in the flow of play, not in the procedure, so it never gets written into the steps. This field is the safety net for that loss.

Why Environment includes server and live-ops events — client settings alone won't catch bugs that split on the same build: ones that depend on a live-ops event or server state. The build number prevents the classic accident where QA saw one build and the developer reproduces on another.

Why reproduction rate sits next to the steps — it stops a 3-out-of-5 bug from being closed as "cannot reproduce" after a single attempt. It's also a hint that the bug is timing-dependent.

Three anti-patterns that keep showing up

1. The title is the whole ticket — a ticket that just says "inventory bug" can't be searched and can't be deduplicated. Enforce the [Where] condition + symptom shape.
2. "UI breaks" with no attachment — visual bugs lose their information the moment they're put into words. A rule that bounces screenshot-less visual tickets actually reduces back-and-forth.
3. "It stutters sometimes" — performance problems can't be diagnosed from felt descriptions. At minimum you need the scene and frequency; ideally an FPS number.

Where the template runs out

Even a perfectly filled template has one problem left: the environment, state, and log fields are reconstructed by a human, after the fact. You notice a bug only after it has happened, so "what happened right before" always passes through memory first.

That's why we built Rekon to fill this template's attachment section automatically — video, logs, and game state, captured at the moment. Why manual recording is structurally always late is covered in a separate post.

The form is a starting point. Add and remove fields to fit your team — but keep "what happened right before" and "environment." Most cannot-reproduce tickets die from those two blanks.