Mobile Testing interview questions
Mobile Testing questions a QA / manual tester can be asked, from first job to senior. Open one to see the strongest answer and why it works.
The app asks for camera permission. What do you test besides tapping Allow?
The strongest answer: Deny it and check the app explains what is lost and still works, revoke it later in system settings and return to the screen, and check what the app does when the user is asked a second time
Why it works: Right — deny, revoke-while-installed and the second ask are where real apps break or trap the user.
- Test the denied path first.
- Deny, then use the feature.
- Revoke in settings, come back.
- Check the recovery message.
You are handed the same feature on Android and iOS. What genuinely differs for a tester?
The strongest answer: Back navigation, the permission dialogs and their wording, keyboard and text handling, notification behaviour, and the spread of OS versions and screen sizes you have to cover
Why it works: Exactly — navigation, permissions, keyboards, notifications and version spread are where one feature behaves differently.
- One feature, two platforms.
- Check back navigation and permissions.
- Check keyboard and notifications.
- Cover each platform’s version spread.
The release candidate installs cleanly on your test device and the team is ready to ship.
What have you not tested yet?
The strongest answer: The upgrade over the previous released version with real data in it — old local data, an old session, an old cached format — which is what nearly every user will actually do
Why it works: Right — the upgrade path carries old data and old sessions, and that is where migrations and stale caches fail.
- Test the upgrade, not the install.
- Start from the released version.
- Put real data in it first.
- Check old sessions and caches.
How do you test a mobile screen against bad network conditions?
The strongest answer: Throttle to a slow profile and check the loading and timeout states, drop the connection mid-request and see whether it retries or duplicates, and switch from Wi-Fi to mobile data during a submit
Why it works: Exactly — slow, dropped and switching are three different failures, and the mid-request drop is where duplicate orders come from.
- Three conditions, not one.
- Slow: check loading and timeouts.
- Dropped mid-request: retry or duplicate?
- Switch networks during a submit.
Users report losing a half-finished form “sometimes” — never while you are watching.
What is your first line of investigation?
The strongest answer: The app being killed in the background: background it under memory pressure or for a long time, come back, and see whether the screen restores its state or starts blank
Why it works: Right — a backgrounded app can be terminated by the OS, and a screen that never saves or restores state loses the form silently.
- Suspect the background kill.
- Background the app under pressure.
- Return and check restored state.
- Save drafts; do not blame users.
How do you decide which devices and OS versions a mobile product is tested on?
The strongest answer: From our install-base data: the versions and screen sizes most users are on, the oldest build we still claim to support, and the vendors our crash reports single out — written down so the gaps are visible
Why it works: Exactly — usage data, the published floor and crash-report outliers, written down so an untested row is a decision and not a surprise.
- Choose the matrix from data.
- Cover the common versions and sizes.
- Include the oldest supported build.
- Write the gaps down.
A mobile app you quality-own can fail store review. Where does QA sit?
The strongest answer: On the guideline and privacy checks before upload, and on the matrix we claim — I do not meet the store for the first time in “rejected”
Why it works: Exactly. Review is a quality gate you can prepare. Rejection is a late oracle.
- Prepare guideline and privacy.
- Test the claimed matrix.
- Do not discover review at rejected.
- Own it with mobile, not after them.