Mobile & device diagnostics

Mobile investigation adds device state, OS behavior, permissions, app lifecycle and hardware constraints. These tools let QA inspect that layer directly while keeping deeper platform testing in the dedicated Mobile curriculum.

App symptom → identify device/app build → adb/Xcode connection → logs/device state → reproduce → correlate with network/API evidence → compare simulator/emulator vs real device

adb fundamentals: devices, install, shell and file access

Android Debug Bridge is a client-server command-line tool for communicating with Android devices/emulators. It can list targets, install APKs, open a device shell, copy files and configure port forwarding.

Practical use: Run adb devices first and target a serial explicitly when more than one device is connected. Record app build/version before installing or replacing anything.

Caveat: adb is mutating and powerful. Shell/file operations can alter app/device state, and USB debugging trust should be managed carefully.

Logcat: filtering signal from noise

Android Logcat aggregates system and application log messages. adb logcat supports tag/priority filtering, which is essential because an unfiltered device stream is noisy.

Practical use: Clear or timestamp deliberately when reproducing, filter by package/tag/priority or process where appropriate, and correlate the log time with the user action.

Caveat: Absence of a debug log does not prove a path did not execute; builds and logging configuration can remove or suppress messages.

iOS bridge: Simulator vs device and device logs

Xcode's Simulator is useful for rapid OS/device-shape coverage, while a real device is necessary for behaviors tied to hardware, radio, performance, permissions and device-specific services.

Practical use: Record whether the issue occurs on Simulator, real device or both. Capture the OS version, model, app build and relevant device logs.

Caveat: Simulator success is not release evidence for hardware-dependent behavior. Conversely, a device-only failure may require device-specific diagnostics rather than UI speculation.

Instruments as a diagnostic bridge

Apple Instruments provides profiling templates for runtime behavior such as CPU, memory and other system activity. For QA it is a bridge to deeper performance/leak diagnosis rather than a complete profiling course.

Practical use: Use a focused recording around the symptom and hand off the trace with app/device/build context to the engineer or performance specialist.

Caveat: A profiler trace needs a hypothesis and comparison baseline; a large trace by itself is not an actionable defect.

Android practical flow — identify device → reproduce → isolate Logcat evidence

Run adb devices -l and confirm the exact device/emulator serial and state.
Build/run the app on that target.
In Android Studio open View → Tool Windows → Logcat.
Start with package:mine. Add level:ERROR when you need errors and above, or use is:crash for application-crash entries. is:stacktrace is useful when the log level alone is not enough.
Reproduce the issue and record the device, app/build version, exact action, timestamp, and relevant stack trace/log sequence.

package:mine & (level:ERROR | is:crash)

Official Android Studio Logcat guide · Official adb guide

iPhone/iPad practical flow — live device logs in macOS Console

Connect the iPhone or iPad to the Mac.
Open Console on macOS and select the connected device in the Devices list.
Click Start to stream log messages.
Reproduce the problem and note the exact time.
Inspect errors/faults and message details around the reproduction time.

Apple Console User Guide — View log messages

Summary

This chapter covers 4 required concepts while keeping tool/formula details tied to a practical decision.
Definitions, scope, assumptions and caveats matter more than a number or a tool name by itself.
Claims that depend on a standard or product are grounded in the source registry below.

Testing & Diagnostic Tools