Question 1
Difficulty: medium
How do you approach testing a mobile app before a release to make sure it is stable across devices and OS versions?
Sample answer
I start by understanding the release scope, the highest-risk user flows, and the device matrix we need to support. From there, I build a test plan that balances core functionality, regression coverage, and device-specific checks. I usually prioritize onboarding, login, navigation, payments, push notifications, and any areas touched in the current sprint. I also verify behavior across a mix of real devices and emulators, making sure to cover different screen sizes, OS versions, network conditions, and permissions states. If time is limited, I focus on what would most affect users or revenue. I like to pair exploratory testing with structured test cases so I can catch unexpected issues without missing critical paths. Before sign-off, I review crash logs, performance trends, and any open defects to decide whether the release is safe or needs more work.
Question 2
Difficulty: medium
Tell me about a time you found a bug that was difficult to reproduce on mobile. How did you isolate the issue?
Sample answer
In one project, users reported that the app occasionally froze after returning from the background, but I could not reproduce it consistently at first. I started by collecting details from support tickets, device models, OS versions, and the exact app state before the freeze. Then I tried to narrow the conditions by switching between Wi-Fi and cellular, locking and unlocking the device, and simulating low memory situations. I also used logs and crash reports to see whether the issue was tied to a lifecycle event or a network call. Eventually, I found that the bug happened when a screen resumed while a background sync was still updating the UI. The fix involved better lifecycle handling and guarding against stale state. What helped most was treating the issue like a pattern investigation rather than a single failed test, and documenting each step so the developers could reproduce it quickly.
Question 3
Difficulty: easy
What types of mobile-specific test cases do you always include in your testing strategy?
Sample answer
I always make sure to include mobile-specific cases that go beyond standard functional testing. That means checking app behavior during interruptions such as calls, notifications, app switching, screen rotation, and device lock/unlock. I also test permission prompts for camera, location, microphone, photos, and push notifications because those can break workflows in subtle ways. Battery usage, network changes, and offline behavior are important too, especially for apps that sync data or rely on APIs. I pay close attention to gesture interactions, small-screen layouts, and accessibility features like font scaling and screen readers. If the app uses device hardware, I test edge cases like camera access, biometric authentication, and storage limitations. My goal is to catch problems that happen only in real-world mobile conditions, because those are the ones users usually experience most.
Question 4
Difficulty: medium
How do you decide what to automate and what to keep as manual testing in a mobile QA process?
Sample answer
I usually automate tests that are high-value, repeatable, and stable enough to maintain over time. That includes smoke tests, login, signup, core navigation, and common regression paths that run on every build. If a workflow is critical and unlikely to change often, automation gives us fast feedback and reduces risk. I keep manual testing for areas that require visual judgment, exploratory work, or frequent product changes, such as new UI flows, animations, and usability checks. I also prefer manual testing for edge cases early in development when the requirements are still shifting. For mobile specifically, I think it is important not to over-automate device-specific quirks unless the team has a strong framework and reliable infrastructure. The best balance is usually a lean automation suite that catches regressions quickly, supported by thoughtful manual testing that focuses on what automation cannot easily evaluate.
Question 5
Difficulty: medium
Describe how you would test a feature that depends on poor network conditions or offline mode.
Sample answer
I would start by mapping the expected behavior in each network state: online, slow connection, intermittent connection, and fully offline. Then I would test how the feature handles retries, cached data, sync conflicts, and user messaging when requests fail. On mobile, network transitions are especially important, so I would check what happens if the user begins an action on Wi-Fi and then loses connection mid-request. I also verify whether the app preserves state properly and whether users can continue working without losing data. If offline mode is supported, I test read and write actions separately because they often behave differently. I use throttling tools and real device testing to simulate realistic conditions rather than just toggling airplane mode. The key is making sure the app fails gracefully, gives clear feedback, and recovers cleanly once the connection returns.
Question 6
Difficulty: medium
How do you collaborate with developers and product managers when you find a bug close to a release deadline?
Sample answer
I try to be precise, calm, and solution-oriented. First, I confirm the bug with clear reproduction steps, screenshots or video if needed, and note the device, OS, build number, and any relevant logs. Then I explain the business impact in plain language so everyone understands the risk. If it is a blocking issue, I work with the developer and product manager to decide whether we should fix, defer, or reduce scope. I also suggest possible workarounds when appropriate, because sometimes a smaller change can get the release back on track. I do not frame it as a QA-versus-development problem; I treat it as a shared decision based on user impact and release goals. In my experience, teams respond well when QA brings evidence, prioritization, and options instead of just reporting that something is broken.
Question 7
Difficulty: medium
What tools and techniques do you use to test Android and iOS apps efficiently?
Sample answer
I like to use a combination of device farms, real devices, emulators, and debugging tools depending on the test objective. For functional testing, I use real devices as much as possible because mobile behavior can differ in important ways from simulators. I rely on tools like Android Studio and Xcode for logs, build inspection, and device debugging, and I use network proxies or traffic inspection tools when I need to validate API calls. For automation, I have experience with frameworks such as Appium and platform-specific test stacks, depending on the team setup. I also make use of crash reporting, analytics, and performance monitoring to spot patterns that tests alone might miss. Efficiency comes from using the right tool for the right problem. I do not try to force everything through one approach if a quicker or more reliable method exists.
Question 8
Difficulty: hard
Tell me about a time you improved the quality of a mobile release process.
Sample answer
In a previous role, releases were often delayed because the team found too many issues at the last minute. I noticed that the problem was not just test coverage, but also the timing of QA involvement. I proposed shifting QA earlier in the sprint so we could review acceptance criteria, identify risky areas, and prepare test data before the build was nearly complete. I also introduced a lightweight release checklist that included device coverage, regression scope, and verification of analytics and push notification behavior. Over time, this reduced the number of surprises right before release and made defect triage much faster. Developers appreciated getting clearer bug reports, and product managers had a better sense of release readiness. The biggest improvement was cultural: QA became part of the planning process instead of a final gate, which led to better collaboration and fewer emergency fixes.
Question 9
Difficulty: hard
How would you test a mobile app feature that uses biometric authentication like Face ID or fingerprint login?
Sample answer
I would test the feature from both a functional and security perspective. First, I would verify that the authentication flow works correctly on supported devices and that the app falls back appropriately when biometrics are unavailable or fail. I would check enrollment states, repeated failed attempts, cancelled prompts, and what happens after the user switches devices or resets biometric settings. I would also make sure the app handles session timeout correctly and does not expose sensitive data before authentication is complete. On the usability side, I would confirm that the prompt appears at the right time, with clear messaging if the device does not support biometrics or if the user has not enabled them. I would also validate behavior after app reinstall, logout, and OS-level changes. For a feature like this, reliability matters because users need to trust the app, and any inconsistency can damage that trust quickly.
Question 10
Difficulty: hard
How do you handle a situation where a feature passes your tests on one device but fails on another?
Sample answer
When that happens, I look for what is different between the devices instead of assuming the feature is random. I compare OS versions, screen size, hardware capabilities, locale, permissions, language settings, and network conditions. I also check whether the issue is related to performance, memory, device-specific rendering, or platform behavior. If needed, I reproduce the test with logs enabled and try to isolate whether the problem is in the app logic or in how the device handles the interaction. I make sure to document the exact environment because that is often the key to solving it quickly. Then I share my findings with the developer and, if possible, test on a few more devices to confirm the pattern. I think of cross-device failures as a signal that the feature may not be resilient enough for real users, so I treat them seriously even if the bug seems isolated at first.
