Automatic bug capture collects available evidence about unexpected software behavior: the visible result, relevant browser context and, with the right setup, technical activity around the event. It can reduce the details a reporter must collect manually. An investigator still needs to establish what failed, which evidence belongs to that attempt and what to test next.
This guide explains how to choose screenshots, manual recordings or instant replay, configure the capture route and check its coverage before relying on it. The acceptance worksheet and example are original planning aids, rather than reports of customer results.
What should be automatic in bug capture?
Separate three jobs: collecting evidence, submitting it and investigating it. Automating collection does not mean a system detects every defect, submits every incident or proves the cause. A captured error can be relevant, incidental or a consequence of another failure.
Define the useful evidence for one workflow. For an export problem, that might be the chosen filter, the export action, the visible response, the browser version and a related request. For a static layout problem, a screenshot and viewport details may be sufficient. Decide what must be present before deciding how much to collect.
Use a bug report template to describe the task and expected result. The capture workflow supplies supporting evidence; it should leave space for the reporter’s explanation and unknown conditions.
Choose a screenshot, recording or instant replay
| Mode | Useful question | Coverage to check |
|---|---|---|
| Screenshot | What did the interface look like at this moment? | The relevant area and error text are visible. A still image does not show the preceding sequence. |
| Manual recording | What happens when someone performs these steps? | The selected source includes the complete task, and the saved playback shows the starting state and result. |
| Instant replay | What recent activity was already captured before the report? | Replay was enabled for that site and the available history contains the event. Check the reconstructed output itself. |
Screendesk’s Chrome extension offers these three modes. Its current product page describes instant replay of the last two minutes and allows replay to be disabled or enabled or blocked by site. Treat the saved replay’s actual coverage as the evidence, rather than assuming an event is available merely because the extension is installed.
The Screendesk changelog describes replay as reconstruction from DOM snapshots. This is a different capture method from recording a selected display as video. Test important dialogs, transitions and embedded content; do not assume a tab replay preserves activity in another application.
Use the capture route that fits the reporter
For an external customer on desktop, a requested recording may be the simplest route. In the documented customer recording flow, the person opens a link, optionally enables their microphone, chooses a screen, window or tab, demonstrates the issue, then stops and submits. This route does not require installing the team extension.
For internal QA or engineering, evaluate the extension on an approved test site. Select the mode that answers the investigation question and inspect the resulting report before expanding the rollout. If replay is blocked for the site, use another supported capture method instead of treating the missing history as evidence that nothing happened.
Keep written notes when capture is declined or unavailable. A task, exact error text, event time and known conditions can still support triage. Avoid repeatedly asking the customer to perform a destructive or consequential action just to obtain a clearer video.
Configure technical context separately from the picture
Screendesk’s current product FAQ states that recordings include browser and device details, while console and network capture require the relevant setup, such as the script on your web app, and a plan that includes developer tools. Recording another application does not automatically include that application’s browser logs.
The script installation guide documents console interception, fetch and XMLHttpRequest monitoring, and interaction/error listeners. A workspace admin can retrieve the workspace-specific snippet. Have the application owner install it and test initialization and Content Security Policy compatibility on the intended pages. Do not copy a demonstration workspace identifier or broadly weaken a security policy to make a test pass.
List required context by purpose: environment details to compare affected setups; console messages to inspect a browser-side failure; request status and timing to investigate a network event; navigation or clicks to align the sequence. Check which fields actually arrive through your selected route. A blank log panel can mean capture was unavailable or misconfigured; it is not proof that the application produced no errors.
Confirm permissions and mobile boundaries
Browser screen capture has its own permission boundary. MDN’s screen-capture API documentation describes user selection, permission and user interaction requirements. For that API, permission cannot be retained for later reuse. Test a declined prompt as well as an accepted one, and provide a workable fallback.
Screendesk’s current FAQ distinguishes desktop browser screen recording from mobile camera video: mobile customers can send footage from their phone camera, while browser screen capture is unavailable on mobile. That camera video does not automatically supply another application’s browser logs. Choose evidence appropriate to the device instead of promising identical capture across desktop and phone.
Test capture with a controlled example
Consider a fictional QA exercise: a test account selects a saved filter, clicks Export and receives “Export unavailable.” The team expects the export to start. This is an illustrative scenario, not a real customer incident or a confirmed diagnosis.
First, capture a screenshot to preserve the error text and selected filter. Next, make a manual recording from the stated starting screen. If replay was already enabled for the test site, inspect whether its recent history includes the selection and failed action. Label the attachments by attempt so two different runs do not appear to be one sequence.
Suppose the captured request panel also contains a server-error response near the export click. Record the endpoint, time and status as observations. Engineering should correlate them with the application investigation; proximity alone does not establish why the export failed.
Finally, ask a second reviewer to open the report using their own authorized access. Can they identify the task, see the failure and distinguish observations from the proposed explanation? Record missing coverage before describing the capture setup as ready.
Copyable capture acceptance worksheet
Use this worksheet to evaluate the capture configuration. It complements the report itself and is not a second general bug-report form.
CAPTURE ACCEPTANCE CHECK Workflow, test site and approved test data: Recorder / extension version and device: Capture owner and investigation recipient: Mode: screenshot / manual recording / instant replay Required visual starting state, action and result: Required technical context and reason: Script / developer-tools / plan setup checked: Permission or site-replay setting checked: Test attempt and event time with time zone: Saved visual evidence inspected: Actual replay range or recording gap: Required context present / absent / unavailable: Sensitive visual AND diagnostic fields reviewed: Recipient access and next action checked: Declined / failed capture fallback tested: Acceptance decision, unresolved gap and owner: Review date and change requiring another test:
Review visual and diagnostic data before sharing
Use approved test accounts and synthetic inputs where possible. Close unrelated material and capture the smallest scope that still shows the task. Review the saved evidence, including URLs, logs and request contents, before moving it to another system. Hiding a field in the picture does not by itself establish that every technical attachment is safe.
Assign responsibility for the permitted audience, evidence destination and retention decision. Screendesk’s sharing documentation distinguishes link access from workspace-restricted received recordings and describes administrator configuration and plan requirements. Check the actual item and workspace settings rather than assuming a link in an internal ticket is restricted.
Run a small pilot and measure usable coverage
Select one workflow and a named receiving investigator. Test the modes and supported environments you intend to offer, plus denied permission, disabled replay, absent context and unsuccessful submission. Define the fallback and owner for each failed check.
Measure capture quality among the attempts actually inspected. For example, an entirely fictional pilot might inspect ten saved test captures and find that eight contain all the pre-agreed evidence: eight divided by ten is 80% completeness for that test set. Keep failed submissions in a separate attempted-submission count; excluding them must not make collection look more dependable.
Review the missing fields with the investigator and change the relevant setup, instructions or coverage requirement. Keep issue type and device visible when comparing later results. Completeness is not detection accuracy, resolution rate or proof of a faster fix. For the wider ownership and investigation process, use the bug reporting best practices guide; for selecting vendors, use the bug reporting tools comparison.
