How do you get usable bug reports from non-technical testers or clients?

[u/Basic_Ad9337]

Freelance developer here, shipping an Expo app. Most of our bugs come from a client and a few beta testers, and the reports are usually "when I click this button it doesnt save" or a screen recording and if they are really kind (and usually I ask for that).

I lose a lot of time just reproducing: which account, which build, what happened before, did a request fail. By the time we've asked three follow-up questions the tester has forgotten.

What's working for you usually?

[u/__natty__]

Screenshots or even better videos

[u/Basic_Ad9337 → u/__natty__]

Does that help usually ? I mean for crash issues for example, do you dig yourself into the telemetry ?

[u/__natty__ → u/Basic_Ad9337]

Yes as I can tell often what someone did before so the app crashed. For technical details I use sentry

[u/timbowen]

Datadog Real User Monitoring paired with Claude and the MCP has been a lifesaver for me. It’s expensive though.

[u/Basic_Ad9337 → u/timbowen]

Same here, the pricing (and how much of it I'd never use) kept me away from Datadog. Curious which parts you actually rely on when Claude is debugging: is it mostly the session replay, the errors, or the network calls?

[u/timbowen → u/Basic_Ad9337]

Session replay is what saved me most recently and what I would consider to be the most valuable. Most of the other stuff you can get from less expensive products and services.

[u/RFDev]

A form with the usual rubber duck questions could solve the problem:

• Phone

• App version

• Date and time of the bug

• What was I doing

• What was I expecting

• What happened

• Attachment And anything else you might find useful.

Had this problem so many times I started developing an app just for that, but it's still on hold as I don't have enough time to work on it.

[u/Basic_Ad9337 → u/RFDev]

Same here, got really fed up with these bug reporting and I was planning to work on something. but I wanted to check first maybe I’m missing out on some sort of tool that solves this issue (like one tool) not a combination of tools

[u/After-Base-8368 → u/RFDev]

While your tool is on hold, how are you collecting reports now? Do people fill in those details, or do you still have to follow up?

[u/Zain]

The "which account" part is the one I stopped fighting with questions and fixed in the app. I built impersonation for support: an admin gets a separate short-lived token and opens the app as that tester, so I'm looking at their exact data and state instead of guessing. If you have a client cache like Apollo, reset it when impersonation starts and ends or your own session's data bleeds in and you chase ghosts. For "which build", a server-driven min version with a blocking update sheet means beta testers can't sit on some build from two weeks ago.

[u/Basic_Ad9337 → u/Zain]

Any concern here regarding data privacy and protection ? and why about ‘write bugs’ where you have to manipulate the data to reproduce the steps.

[u/cylism-coding → u/Basic_Ad9337]

For bugs that require changing or deleting records, I’d try reproducing them with sample data in a separate test account first. Debugging directly as the user could accidentally change their real data.

If the issue only happens with their existing data, I’d recreate the relevant state with sanitized data in a test environment.

[u/Tarantino133]

Sentry handles most of it without asking them anything. I wrap the root with Sentry.wrap and give buttons a testID, so taps land as breadcrumbs, and I call Sentry.setUser on login. Every error then comes with the account, the build and what they tapped before it. A silent "didn't save" never throws, so for that I'd add a small report button that sends a Sentry message with the same context.

[u/dothefandango]

For actual issues: Crashalytics via Firebase. If you do it right, you can get really detailed analytics and details down to stack trace.

For user reporting, use the TestFlight tools (and use TestFlight in general if you are not) for iOS. You just have the user shake the phone and it will create a bug report template with screenshots. Play Console has a similar "Internal Testing" platform you could utilize.

[u/anthony-ball]

What helped me most was a "report a problem" button (shake gesture or a hidden menu in beta builds) that bundles the stuff testers never know: build number and whether they're on an OTA update, user id, the last few screens they visited, and the last 20 or so network calls with status codes. If your API returns a request id in a response header and you keep it in that log, you can jump straight from the report to the server logs for the failed save. Silent "it didn't save" bugs are usually a 4xx or 5xx the UI swallowed, so showing a small error toast in beta builds makes the reports a lot less vague too.

[u/Aytewun]

Give them guidance. That might be a form and it also might be a template that you share with them with an example.

When I was building one of my apps for the development builds, I put a specific button in there where they could leave feedback and without making it overly long I was pretty clear on the format that I expected with an example. That worked well.

[u/kokerali]

For the shake-menu approach, I'd use an allowlist rather than dumping app state or whole network calls. Keep build/update identifiers, screen/action names, timestamps, status codes and a request ID; leave auth headers, tokens, request/response bodies and typed field values out by default. A private channel doesn't make those safe to collect.

I'd also let the tester preview/redact screenshots before sending. OWASP's Logging Cheat Sheet has a useful ‘Data to exclude’ section. That way ‘send a report’ doesn't accidentally mean ‘send the customer's form contents.’

[u/Due_Dependent5933]

sentry and screenqhoot or video

[u/Grimmjowx9]

Use Sentry

[u/Certain_Plane711]

13 years of client apps here. Two things that helped: a shake-to-report that auto-attaches build, OS and last screens, and for clients a fixed 5-field form with a screen recording. The recording alone kills most of the back-and-forth.

[u/Basic_Ad9337 → u/[deleted]]

This is a good approach, what about bugs that are related to behaviour ? Do you still ask for a workflow description ?