What we learned talking to mobile QA teams about bug reporting

We recently held four customer-development conversations with people working in and around mobile teams. Two were at large or established consumer businesses; two were former coworkers with direct experience of shipping and testing apps.

Four interviews are not a market survey. They are enough to challenge a weak assumption, spot language that repeats, and decide what to ask next. Here are the five signals that changed our thinking.

1. Manual bug reporting is still normal

Across very different teams, reporting remained strikingly manual. Someone notices a problem, opens a tracker or sends a message, and reconstructs enough detail for another person to understand it. One participant estimated a complete manual ticket at about 15 minutes.

The problem was familiar even inside organisations with mature engineering stacks. Better crash monitoring had not removed it because many of these reports began with a person noticing something, not with an exception.

2. Device metadata is useful, but not the wedge

We expected automatic device, OS, and build details to carry more weight. Interviewees treated them as helpful background rather than the hard part. Writing steps to reproduce—and recovering which test account exposed the problem—created more friction.

So we changed the message. Metadata remains attached to BugScreen reports, but it is reassurance, not the headline.

3. Crash telemetry and human reports are separate lanes

Firebase Crashlytics already owns a clear job: automatically reporting production crashes and errors. Competing with it would be both unnecessary and confusing.

The durable boundary is automated telemetry versus human-reported bugs. A layout glitch, wrong piece of copy, or strange account-specific flow may never throw an error. It still needs a short path from the person who saw it to the team that can fix it.

4. App Distribution has a reporting gap

Firebase App Distribution repeatedly appeared as the way teams deliver development builds. It gets software to testers; it does not turn every observation into a ticket in the team's preferred format. That makes the workflow complementary: distribute with Firebase, capture the human report inside the build, and file it to Jira, GitHub, or ClickUp.

5. UAT may feel the pain more sharply than trained QA

One participant volunteered stakeholder testing as a use case. Trained QA professionals know how to write a report, even when the process is slow. A product manager, client, or operational stakeholder may spot an important UI problem without knowing how to describe environment details or navigate an engineering tracker.

That makes low-friction capture particularly valuable for UAT. The reporter can take a screenshot, add a short description, and let the system handle filing and technical context.

What we are doing—and not claiming

These conversations produced a clearer positioning line: human-reported bugs become useful tickets; Crashlytics and Sentry keep doing telemetry.

They also surfaced product directions around reproduction context, test accounts, and appearance mode. Those are directions until they ship. Today BugScreen captures a screenshot, the tester's description, logs, and environment context and files the result to the connected tracker. The useful discipline is to let research sharpen the roadmap without letting the roadmap leak into present-tense marketing.

Next, we want to learn how teams identify the active test account today and what evidence they would trust as a draft of reproduction steps. The interesting part of customer development is not hearing your pitch repeated back. It is finding the sentence that makes you rewrite it.