How to file a screen recording bug report
· Harsh Khatri
A screen recording bug report is a clip plus a pointer — not a diary. The recording should make the failure obvious in under thirty seconds of playback. Everything else is optional, including your voiceover.
Before you hit record
Hide the unrelated tabs. Use a test account you can name in the ticket. Note the build. If you need auth, start recording after you are in — login flows eat the first minute and nobody needs your password manager.
If this is a bash, prefer one recording per charter, not one six-hour desktop capture.
During
Go slowly enough that a stranger can see the click. Narrate only if you will not write steps later. Silence is fine. Mouse flailing is not.
When the bug happens, linger on the broken state. Then stop. Do not keep recording “while I try a few more things” unless those things are new bugs — in which case you will mark them separately.
After: the report, not the file
Upload or attach the recording. Mark start/end. Write expected vs actual. Draw if the frame is busy. Then put it in Jira as a ticket, not as “see video.”
If you used Loom, still copy a timestamp into the ticket. A Loom without a time is a screenshot’s lazier cousin.
Turn a recording into marked bugs
Related
FAQ
How long should a screen recording bug report be?
Aim for a time window under 30–60 seconds around the failure. Keep a longer source file if you must, but do not make engineering scrub it.
Do I need audio on a bug recording?
No. Audio helps if you will not type steps. It hurts if it is a stand-up conversation over the bug. Prefer on-screen evidence plus written expected vs actual.