Screenshots are the most common bug reporting artifact. They're also the least useful one for the developer who has to fix the bug.
A screenshot tells you what a bug looks like. It doesn't tell you what caused it. And cause is what developers need. Without it, every screenshot-only report generates the same follow-up questions: "What were you doing before this? What's in the console? What did the API return?"
Here's why screenshots aren't enough — and what to pair them with.
What Screenshots Capture
A screenshot captures a single frame of a single moment: what the page looked like when the user pressed the screenshot button. It captures:
- The visual state of the UI at that moment
- Any visible text, including error messages
- The layout and rendering at the moment of capture
What Screenshots Don't Capture
Screenshots don't capture any of the following — and this is where bugs live:
The Path to the Bug
What did the user do before the screenshot? What sequence of actions created the conditions that caused the failure? A screenshot shows the failure but not the path to it.
Developers need to reproduce the path, not just the result. "The page shows an error" is less useful than "the user navigated from /cart to /checkout, entered billing info, clicked Submit, and got an error on /payment-confirm." The screenshot gives you the first sentence. Session replay gives you the whole story.
The Application State
A screenshot shows what the page rendered. It doesn't show what data the page contained. Two pages can look identical in a screenshot but have completely different underlying data. For data-driven bugs — wrong calculations, missing records, unexpected values — the relevant information is in the data, not the visual.
A page state snapshot captures the actual DOM with actual data values: what was in the table cells, what values the form fields contained, what the component's props were. A screenshot of a table showing "$0.00" is a symptom. The page state showing the component received null from the API is the cause.
Console Logs
Most bugs generate a JavaScript error. Screenshots don't include console output. Without the console log, the developer has to reproduce the bug and look for errors themselves — which requires knowing how to reproduce it, which requires knowing the path, which requires the information that wasn't in the screenshot.
Network Responses
If the bug involves wrong data from the backend, the cause is in the API response. Screenshots don't include network traffic. The developer has to make the same API call in their environment, which may return different data than what the user experienced.
The Modern Bug Report
A modern bug report includes:
- Screenshot: What it looked like — still useful for visual context and annotation
- Session replay: What the user did — the path that created the conditions
- Page state snapshot: What data was there — the application state at failure
- Console logs: What errors occurred — the technical signal
- Network payloads: What the API returned — the root cause for data bugs
With all five, a developer has everything needed to diagnose and fix the bug without asking a single follow-up question. With only a screenshot, they have 20% of what they need.
Tools That Capture More Than Screenshots
Manual collection of session replay, page state, console logs, and network payloads is impractical. It requires opening DevTools for every bug, running specific commands, and pasting output into the report. Most QA testers don't have the technical background to do this reliably.
The practical solution is a tool that captures all of this automatically when the reporter clicks Submit. SnagRelay does exactly that — every report automatically includes session replay, page state, console logs, and full network payloads. The QA tester provides the observation (what they saw and what they expected). The tool provides the technical context. The developer receives everything they need.
