For QA engineers
Session Replay for QA and Bug Reproduction
Intermittent bugs are hard because nobody saw them happen. How QA teams use AnyReplay DOM recording, error flags and the chunk timeline to see what a user did.
Updated · 5 min read
The hardest bugs to fix are the ones nobody can reproduce. The report says the total was wrong once, on a Tuesday, for one customer, and every attempt since has produced the right number. Session replay for QA turns that report into a recording of the exact sequence of states the page went through, which is usually enough to see where the wrong number came from.
This page covers what DOM recording captures that a screenshot cannot, how error flags and the chunk timeline point at the failing moment, and what AnyReplay does not record.
The problem: reproduction depends on what the user did, not what they said
A bug report is a compressed and lossy description of a sequence of events. Users omit the step that mattered because it seemed irrelevant: they pasted instead of typing, they opened the page in a second tab, they went back with the browser button rather than the in-app one. QA engineers then spend hours trying permutations, and the ticket is closed as cannot reproduce when they run out.
Intermittent bugs are worse. A race between two requests shows up in one session in fifty. Logs capture the server side; nothing captures what the page looked like in between.
How replay fits a QA workflow
Replay changes the first step of triage from asking for steps to watching them. A session replay in AnyReplay is a DOM recording: the SDK wraps rrweb, takes a full snapshot of the document when recording starts, then records every mutation, input change, scroll and click as an incremental snapshot. Playback rebuilds the real DOM state at any instant, so you can pause on the frame where the total was wrong and inspect what the page contained, not what it looked like from a distance.
Finding that frame is the second step. Events are uploaded in chunks of up to 200 events or every five seconds, whichever comes first, and every chunk carries flags: hasError when a script error occurred during it, hasRageClick when the user clicked the same spot three times within a second, and pageCount for navigations. The timeline shows chunks in sequence, so a QA engineer opens the session, jumps to the first chunk with hasError, and starts a few seconds earlier.
Chunks are numbered, and the ingest service is idempotent: a chunk uploaded twice answers 202 with duplicate: true and a hint for the next sequence number, so a flaky connection cannot produce a session with repeated events. The chunked upload entry describes the sequence guarantees.
What AnyReplay does for QA teams
The real state, not a picture of it
A screenshot tells you what was rendered. A DOM recording tells you what was in the document: the value the select actually held, the disabled attribute on the button, the class that was toggled twice. The post rrweb explained covers the recording mechanism in detail.
A replay that cannot run code in your browser
Replaying someone else's page means replaying their scripts, which is a problem when the page is a customer's and the reviewer is you. AnyReplay closes it in three layers. rrweb replaces script bodies with a placeholder at record time, so script source never leaves the customer's page. On replay, scripts are rebuilt as noscript. The player iframe is a sandbox iframe without allow-scripts, verified in a real browser, and a test fails the build if anyone enables the rrweb option that would add it. A recorded page cannot execute anything on a reviewer's machine.
Mobile bugs recorded as elements, not pixels
For React Native apps, the React Native SDK records the committed element tree: what each component is, what text it holds, and where it was laid out. That is a wireframe with real text, so a QA engineer can see that a label was truncated or a button never mounted, and can search a session for the text of the failing screen. It works in Expo Go on SDK 52 or later with no native module; the mobile app teams page lists its limits.
Sessions in any language
When a bug report comes from a user in another market, session translation lets the engineer watch the recorded interface in their own language. Translation is applied to the event stream before playback, so the timeline stays translated when they scrub.
What is not recorded
AnyReplay records the DOM and user interactions. It does not capture console output, network requests or stack traces; the hasError flag tells you that an error occurred in a chunk, not what it said. Pair the recording with your error tracker or server logs using the session ID from getSessionId(). Masked inputs replay as asterisks and this cannot be undone after the fact, so a bug that depends on the exact value typed into a masked field needs that value from the user or the server. See the privacy page for the masking rules.
Getting started
- Create a project. The Free plan includes one project and 500 sessions per month; see pricing for the current plans.
- Install the SDK snippet on your staging and production sites, or run
npm install @anyreplay/react-nativefor a mobile app. Leave field masking on unless you have reviewed every field. - Ship. Add the session ID to your bug report template so testers and users can link a report to its recording.
- When a report arrives, open the session, jump to the first chunk flagged
hasErrororhasRageClick, and watch the ten seconds before it.
Frequently asked questions
Does AnyReplay record console logs or network requests?
No. It records DOM changes and user interactions. Chunks carry a hasError flag that says an error occurred, not its message. Use the session ID to correlate with your error tracker or server logs.
Can I see what the user typed into a form?
Only if you opt out. Form values are masked by default and maskAllInputs: false records them; passwords and card fields are masked whatever you set, and masking happens in the browser, so a masked value cannot be recovered later.
Is it safe to replay a session recorded on an untrusted page?
Yes. Script bodies are removed at record time, scripts are rebuilt as noscript on replay, and the player iframe is sandboxed without allow-scripts. A test fails the build if that sandbox is weakened.
Can I replay the session against my own build to reproduce the bug?
No. Replay reconstructs the recorded DOM; it does not drive the user's actions against a live page. It shows you what to do, and you do it in your own environment.