Q6 of 26 · Mobile QA

What extra context does a mobile bug report need compared to a web bug report?

Mobile QAJuniormobilebug-reportingprocessdocumentation

Short answer

Short answer: Device model, OS version, screen size and density, carrier and connectivity type, app build number (not just version name), app state at the time (foregrounded, backgrounded, after sleep), and a screen recording showing the gesture or transition — screenshots rarely capture a motion-based bug.

Detail

A web bug report needs browser, OS, and steps. A mobile bug report needs all of that plus a much richer device context, because the same APK or IPA can behave differently across hundreds of device/OS combinations.

Device specifics that matter: manufacturer (Samsung vs Pixel vs OnePlus), model (A54 vs S24 Ultra), OS version (Android 12 vs 13), and whether the device has an OEM skin (Samsung One UI changes default font sizes, some Xiaomi ROMs override system alerts).

App state context: did the bug occur on first install, after an update, after the app was backgrounded for 20 minutes, after a phone call interrupted the session? These are common root causes that a web bug report never needs to address.

Screen recordings over screenshots: most mobile bugs involve transitions, gesture failures, or layout shifts. A two-second screen recording is worth ten screenshots. Always attach one for gesture-related or animation-related bugs.

Crash logs: Android stack traces are in logcat; iOS crash reports are in Device > Privacy & Analytics. Always attach them for crashes — developers cannot reproduce without them.

// WHAT INTERVIEWERS LOOK FOR

Goes beyond the web-report fields to name mobile-specific context: device details, app state, and screen recording as the primary evidence type.