Screenshot and screen-record workflows for QA

Most reporters waste 30 to 60 seconds per bug switching between screenshot tool, file system, and the tracker. Compounding over a sprint, that is hours lost per QA engineer — and worse, it is friction that quietly discourages people from filing the small bugs that would otherwise get fixed.

Three habits remove almost all of that cost. None of them require new software. All of them pay back the time you spend learning them within a single day of QA.

1. Learn your OS screenshot shortcuts cold

If you reach for a third-party app for every screenshot, you are paying a tax the OS already removed. Memorise the native shortcuts for region capture and recording. Practise once, use forever.

• macOS — ⇧⌘4 for region screenshot, ⇧⌘5 for recording. Hold Ctrl with ⇧⌘4 to copy to clipboard instead of saving a file.
• Windows 11 — Win+Shift+S for region (Snipping Tool), Win+G for the Game Bar recorder.
• Linux GNOME — Print Screen opens the screenshot UI with region, window, and screen modes plus recording.
• Linux KDE — Spectacle handles screenshots, OBS Studio is the standard for recording.

2. Paste, do not upload

Modern trackers accept paste from the clipboard. In dontslowme, Ctrl/Cmd + V on an open bug attaches the image instantly — no save dialog, no file picker, no "where did I put that PNG". This single shortcut typically halves the time per report.

The workflow becomes: capture region to clipboard → switch to the bug card → paste. Three steps, under five seconds, no file system involvement.

3. Annotate at capture time, not later

A red arrow on the broken element saves reviewers seconds and prevents "where am I supposed to be looking?" comments. Both macOS Markup and the Windows Snip tool let you annotate immediately after capture, before the image hits the clipboard.

• Arrow pointing at the broken element.
• Box around the area of interest.
• Short text label — one or two words, no full sentences.
• Red or yellow only, so the annotation reads against any background.

When to record video instead

Use video when the bug is timing-dependent, involves a sequence of clicks, or shows visual jitter that a single frame cannot. The rule of thumb: if you would have to write more than three sentences to describe the sequence, record it instead.

Keep recordings under 30 seconds. Long videos rarely get watched in full, and the engineer ends up scrubbing for the moment of failure. If you need to show setup, do it in text and let the recording start one second before the failure.

Recording checklist

1. Close unrelated tabs and notifications — Slack popups in a bug video look unprofessional.
2. Pick the smallest sensible region (a single browser window, not the whole desktop).
3. Start recording before the action, stop within 2 seconds of the failure.
4. Save as MP4 or WebM, not MOV — smaller files, better browser support.
5. Attach the recording and add a 1-line description: "failure at 0:07".

What to capture in the screenshot

• The broken element, large enough to read.
• Enough surrounding context to identify the page.
• The URL bar if the page identity matters.
• Any error text — the literal string, not your paraphrase.
• The developer console if a JS error is visible.

Privacy hygiene

Before pasting, glance at the image for personal data: real customer emails, names, payment details, internal API keys in network panels. Redact with a black rectangle in your annotation tool. Most leaks happen not through breach but through bug reports captured carelessly.