82 mobile testing interview questions with answers

What they are assessing

The classification that determines the whole test approach.

Model answer

A native app is built with the platform toolkit, Swift or Objective-C for iOS and Kotlin or Java for Android, installed from the store with full access to device capabilities. A mobile web app runs in the browser with no installation. A hybrid app is a web application wrapped in a native shell, rendering in a web view while having some native access. Cross-platform frameworks such as React Native and Flutter sit alongside these, compiling to native components from a shared codebase. The distinction matters because it determines the locator strategy, what can be automated, and which failure modes are plausible.

Likely follow-up

How would you tell whether a screen is native or a web view?

What they are assessing

Whether the candidate sees why mobile needs its own discipline.

Model answer

The device is part of the system under test, so hardware, operating system version, manufacturer customisation and available resources all affect behaviour. Connectivity is variable rather than assumed. The app can be interrupted at any moment by a call, a notification or the operating system reclaiming memory. Installation and upgrade are real scenarios rather than a deployment detail. Battery, data usage and app size matter to users. And releases go through store review, so a defect cannot simply be hotfixed within the hour.

What they are assessing

Where testing effort should concentrate.

Model answer

Fragmentation across devices and operating system versions. Interrupts and the app lifecycle, since an app can be backgrounded and killed at any point and must restore correctly. Network variability including loss mid-operation. Permissions, which users can grant, deny or revoke at any time. Resource constraints such as low memory and low storage. Upgrade paths, where existing users carry data from previous versions. And the store release process, which limits how quickly a defect can be corrected.

What they are assessing

Current development reality.

Model answer

React Native, Flutter and similar let one codebase target both platforms, rendering native or near-native components. For testing, the shared codebase means business logic defects usually appear on both platforms, so finding one implies checking the other, while platform-specific defects now cluster around the bridge to native capabilities and around platform conventions the framework abstracts imperfectly. It does not remove the need to test both platforms, which is the assumption teams adopting these frameworks most often make.

Trap to avoid

Assuming a shared codebase means testing one platform is sufficient. The framework abstracts the common case and the divergence appears exactly where the platforms genuinely differ.

What they are assessing

Practical platform knowledge.

Model answer

Fragmentation: Android spans many manufacturers, versions and screen configurations, while iOS has a narrow device set and fast adoption of new versions. Navigation: Android has a system back gesture or button that must be handled on every screen, iOS does not. Permissions differ in presentation and in revocation behaviour. Background execution is far more restricted on iOS. Distribution and review differ, with Apple review stricter and slower. And on the automation side, iOS requires a Mac for building and for running the native driver.

Likely follow-up

Which of those causes the most defects in your experience?

What they are assessing

A platform-specific behaviour that is routinely broken.

Model answer

Because it is a system-level action the app must respond to on every screen, and the correct behaviour differs by context: it should dismiss a modal, step back through a flow, exit a nested navigation stack, and from the root it should leave the app. Common defects are a back press from a form losing entered data without warning, a back press skipping a step and leaving inconsistent state, and a back press from the first screen after login returning to the login screen while still authenticated. Gesture navigation on newer versions adds a variant that behaves slightly differently.

What they are assessing

A significant source of defects.

Model answer

Permissions are requested at the point of use and can be granted, denied, denied permanently, or revoked later in settings, and on recent versions some are granted only while the app is in use or only once. Each state needs testing, and the one most often broken is permanent denial, where the app must explain and route the user to settings rather than repeatedly prompting or crashing. Revocation while the app is backgrounded is also significant, because on Android the process is restarted when permissions change, which exposes state restoration defects.

Trap to avoid

Testing only the granted path. Denial and revocation are where mobile apps crash, and they are trivially easy to produce.

What they are assessing

Android-specific risk.

Model answer

Android manufacturers ship modified builds with their own interface layers and, more importantly, their own battery and background process management, which is aggressive on several popular brands. The practical consequence is that background work, scheduled jobs and push notification delivery can behave differently on one manufacturer than on stock Android, and those differences produce defects that are impossible to reproduce on an emulator or on a different handset. It is a strong argument for a device matrix driven by the manufacturer share of the actual user base rather than by model age.

What they are assessing

A distinction frequently stated loosely.

Model answer

An Android emulator emulates the hardware and runs a full system image, so it is closer to a real device but slower. An iOS simulator does not emulate hardware: it runs the app compiled for the host architecture against a simulated environment, which makes it fast and means it diverges more from a real device. Practically, both are useful for rapid functional checking and neither is adequate for performance, battery, camera, sensors, biometrics, real network behaviour or manufacturer-specific issues.

Likely follow-up

Which defects would only appear on a real device?

What they are assessing

The central planning question.

Model answer

From the actual user base rather than from a general popularity list, using analytics to rank devices and operating system versions by share of sessions, weighted by business value since a small segment of high-value users may justify coverage. Then I would add the extremes deliberately: the oldest supported version, the smallest and largest screens, and a low-specification device, since those surface layout and performance defects a mid-range current handset will not. The matrix is reviewed each release rather than fixed, because the distribution moves.

What they are assessing

A real procurement decision.

Model answer

A cloud gives breadth without capital cost or maintenance, scales for parallel execution, and keeps pace with new devices. Its weaknesses are cost at high usage, latency that makes interactive debugging painful, restrictions on some capabilities such as certain hardware features, and the need to get test builds and data to a third party, which raises data protection questions for some sectors. An in-house lab gives full control and low marginal cost, at the price of device procurement, charging, flashing, maintenance and a device that is always missing. Most mature teams use a small in-house set for daily work and a cloud for matrix coverage.

What they are assessing

Forward planning that teams often skip.

Model answer

Through the beta programmes both platforms run, installing the developer or public beta on dedicated devices and running the regression suite against it well before general availability. The reason it matters is that an operating system release reaching users will break apps that assumed old behaviour, and the fix then has to go through store review while users are already affected. The specific things to check are permission model changes, background execution restrictions, deprecated APIs and any change to the privacy rules, since those are where each annual release tends to break things.

What they are assessing

Breadth of the basic pass.

Model answer

The core journeys end to end. Input validation and keyboard behaviour, including the correct keyboard type per field and whether the keyboard obscures the input. Orientation change on every screen that supports it. Navigation including the back action. Permissions in all their states. Offline and poor connectivity. Interrupts such as a call or notification mid-flow. Background and resume. And the visual pass across screen sizes, since layout defects are the most common mobile finding.

What they are assessing

A specific and defect-prone event.

Model answer

That the layout adapts without truncation or overlap, that entered but unsaved data survives, that scroll position and selection are retained, and that an in-progress operation such as an upload continues. On Android the activity is recreated by default on rotation, which is precisely why state is lost, so rotation is an efficient way to find state restoration defects. Rotating during a transition or while a dialogue is open is the variation that most often crashes.

Likely follow-up

Why is rotation a good general test of state handling?

What they are assessing

An entry path that bypasses normal navigation.

Model answer

By opening the link in each relevant state: app not installed, which should route to the store or a web fallback; app installed but not running; app running in the background; and app in the foreground on a different screen. Then the authentication cases, where a link to a protected screen must prompt for login and return the user to the intended destination afterwards rather than dropping them at the home screen. Malformed and tampered links should be handled safely rather than crashing, which is also a security consideration.

What they are assessing

A feature with many states and a lot of defect surface.

Model answer

Delivery in each app state: foreground, background and terminated, since handling differs and the terminated case is the one most often broken. Tap behaviour, which should deep link to the relevant content rather than the home screen, including when the app must authenticate first. Permission denied, where the app should still function and should not prompt repeatedly. Content correctness and that nothing sensitive appears on a locked screen. Grouping and badge counts. And delivery on devices with aggressive battery management, where notifications may be delayed or dropped entirely.

What they are assessing

A scenario routinely omitted.

Model answer

Because most of the user base upgrades rather than installing fresh, so the upgrade path is the common case and the fresh install is the exception, which is the opposite of how most teams test. It involves installing the previous released version, using it to create realistic data and settings, then upgrading in place and verifying that data migrates correctly, the session persists, preferences are retained and no screen crashes on data created by the old schema. Upgrading from two or three versions back also matters, since not everyone updates promptly.

Trap to avoid

Testing only fresh installs. A migration defect affects the entire existing user base and is invisible to a clean install test.

What they are assessing

A specific and damaging failure class.

Model answer

The local database or stored preferences change shape between versions, and the migration either fails or silently loses or corrupts data, which can be unrecoverable for the user since the data existed only on the device. Finding them requires realistic old data rather than an empty app, so the method is to keep a library of saved application states from previous versions and restore them before upgrading. Testing the migration path from each supported prior version is the only reliable approach, since a migration chain that works from the immediately previous version can fail from two back.

What they are assessing

The onboarding path.

Model answer

Onboarding and any permission requests, including what happens when each is denied. That the app works before the user signs in, where that is supported. Initial data download on a poor connection and whether progress and failure are communicated. Default settings being sensible. And that a reinstall after an uninstall presents the correct experience, which for a returning user may need to differ from a genuinely new user, and is a case that is almost never considered.

What they are assessing

A defining mobile concern.

Model answer

By simulating the conditions rather than hoping to encounter them: network throttling tools on device or in the cloud provider, a proxy that can delay and drop traffic, and airplane mode for complete loss. The cases that matter are slow but working, intermittent, and loss partway through an operation such as a payment or an upload. The last is the most important and the least tested, because it determines whether the user ends up with a duplicate transaction, a lost one, or an accurate error.

Likely follow-up

What should happen if the connection drops after a payment request is sent?

What they are assessing

Expected behaviour rather than how to produce it.

Model answer

Fail safely and informatively. It should not leave the user unsure whether the action succeeded, which means either retrying idempotently or stating clearly that the outcome is unknown and offering a way to check. It should preserve any data the user entered rather than discarding the form. It should not hang indefinitely, which requires a timeout. And when connectivity returns, queued actions should complete without duplication, which is where idempotency on the server side becomes the determining factor.

What they are assessing

A transition that produces real defects.

Model answer

Moving between WiFi and cellular, which happens constantly as users leave buildings, and which changes the IP address and can drop existing connections. The defects it produces are requests failing at the moment of transition, sessions invalidated by a server tying them to an address, uploads restarting, and streaming or socket connections not reconnecting. It is easy to produce by toggling WiFi mid-operation and is rarely in a test plan despite being an everyday user experience.

What they are assessing

A feature with its own correctness problems.

Model answer

By verifying what is available offline matches what was promised, that changes made offline are queued and clearly marked as pending, and that synchronisation on reconnection is correct. The hard part is conflict: when the same record was changed on the device and on the server, the resolution rule must be defined and tested, and most apps have not thought it through. Also worth testing is a long offline period producing a large queue, and the app being killed while changes are pending, which must not lose them.

What they are assessing

A category specific to mobile.

Model answer

Tests of what happens when something external takes over while the app is in use: an incoming call, an SMS or notification, an alarm, a low battery warning, the user switching to another app, the screen locking, a headphone or charger being connected, and the operating system terminating the app to reclaim memory. The app should pause gracefully and resume in the same state, with any in-progress operation either continuing correctly or failing cleanly. Interrupting during a transaction is the case that matters most.

Likely follow-up

How would you simulate the operating system killing a backgrounded app?

What they are assessing

A frequently misunderstood Android behaviour.

Model answer

When an app is backgrounded, the operating system may terminate its process to reclaim memory while the user still perceives the app as running. On return, the system restores the activity stack but the process starts fresh, so anything held only in memory is gone. Apps that keep state in memory rather than persisting it crash or show empty screens on return, and users experience this as the app losing their work. It is testable through developer options on Android, and it is one of the highest value tests available because it is common in the field and rarely covered.

Trap to avoid

Assuming backgrounding and process death are the same test. The app resumes normally from a background state and must rebuild from nothing after process death.

What they are assessing

Resume behaviour.

Model answer

That the screen state is intact including entered data and scroll position, that any session or token has been refreshed if it expired while away, that time-sensitive data is refreshed rather than shown stale, that any security requirement such as re-authentication after a period is applied, and that in-progress operations resumed or failed cleanly. Returning after a long interval is a distinct case from returning after a few seconds, and both matter.

What they are assessing

Breadth beyond response time.

Model answer

App launch time, distinguishing cold, warm and hot starts, since cold start is what users judge. Screen transition and scroll smoothness, measured as dropped frames. Memory footprint, since high usage increases the chance of being terminated in the background. CPU usage, which drives battery drain and heat. Network data consumption, which costs users money on metered connections. App download size, which affects install conversion. And battery drain, particularly from background activity.

Likely follow-up

What is the difference between a cold, warm and hot start?

What they are assessing

A specific Android failure.

Model answer

An Application Not Responding error, raised when the main thread is blocked beyond a threshold, around five seconds for input events, and the system offers the user the option to close the app. It is caused by doing work on the main thread that belongs elsewhere: network calls, database queries, file reads, heavy computation or image processing. It is more likely on low-specification devices and under poor network conditions, which is exactly why a mid-range test device on office WiFi will not reveal it. ANR rates are reported in the Play Console and are a release quality gate.

What they are assessing

A measurement teams rarely attempt.

Model answer

By measuring rather than estimating, using the platform tooling: battery historian and the battery stats on Android, and the energy instrument in Xcode for iOS, over a defined usage scenario with the device in a controlled state. The things to look for are background activity that should not be running, wake locks held longer than necessary, excessive location updates, frequent network polling instead of push, and unoptimised rendering. A comparison against the previous release on the same scenario is more useful than an absolute number, since absolute battery figures are very device-dependent.

What they are assessing

Why the device matrix matters for performance.

Model answer

By actually having one in the matrix, because performance defects are frequently invisible on a current flagship and severe on a three-year-old mid-range handset, which is what a large part of the user base is using. The scenarios that expose problems are cold start, scrolling long lists, screens with many images, and operating with low free memory and low free storage, both of which can be induced deliberately. Running the same measurements across the tiers of the matrix gives a profile rather than a single number, which is what tells you whether a regression affects everyone or only the slowest devices.

What they are assessing

Mobile-specific user experience concerns.

Model answer

Touch target size, since controls that are easy to click with a mouse are easy to miss with a thumb. Reachability on large screens, where important actions sit out of reach of one-handed use. Keyboard behaviour, including the correct keyboard type and whether it covers the field being typed into. Scroll and gesture conflicts, such as a horizontal carousel inside a vertical scroll. Feedback for actions, since a tap with no visible response leads users to tap again. And the experience in sunlight and with one hand, which are real conditions rarely considered.

What they are assessing

A legal requirement in many sectors and a commonly thin area.

Model answer

With the actual assistive technology rather than only a scanner: TalkBack on Android and VoiceOver on iOS, navigating the app without looking at the screen, which immediately reveals unlabelled controls, incorrect reading order and elements that cannot be reached. Then dynamic type at the largest setting, which breaks layouts. Then colour contrast and whether colour alone conveys meaning. Then touch target sizes against the platform guidance. Automated scanners such as the Accessibility Scanner catch the mechanical issues and cannot tell you whether the experience is usable.

Likely follow-up

What does a screen reader reveal that an automated scanner cannot?

What they are assessing

An area with predictable defects.

Model answer

Text expansion, since German and several other languages are substantially longer than English and will overflow buttons and labels designed to fit. Right to left layouts for Arabic and Hebrew, where the entire interface must mirror including icons indicating direction. Date, time, number and currency formats. Sorting order. Pluralisation rules, which differ by language and are frequently handled with a naive two-case approach. And that no text is hardcoded, which shows up as untranslated strings appearing among translated ones.

What they are assessing

Mobile-specific security concerns.

Model answer

Data at rest on the device, since anything stored unencrypted is accessible on a rooted or jailbroken handset and sometimes through backups. Credentials and tokens belonging in the keychain or keystore rather than in preferences or a local database. Transport security including certificate validation and, for sensitive apps, certificate pinning. Logging, since tokens and personal data written to the device log are readable. Screenshots in the app switcher, which can expose sensitive screens. And whether the app detects a compromised device where that is warranted.

What they are assessing

A control with direct consequences for the test process.

Model answer

The app validates that the server certificate matches a specific expected certificate or public key, rather than accepting any certificate signed by a trusted authority, which defeats interception by a proxy. It matters for testing because it prevents the usual approach of inspecting traffic through a proxy, so teams need a debug build with pinning disabled or a mechanism to add a test certificate. The important part is testing that pinning actually works in the release build, which means attempting interception and confirming the connection is refused, and verifying the debug bypass cannot reach production.

Trap to avoid

Only ever testing a build with pinning disabled. Nobody then verifies the control works in the build that ships.

What they are assessing

Awareness of a standard for this domain.

Model answer

The Mobile Application Security Verification Standard, which defines security requirements for mobile apps across categories including storage, cryptography, authentication, network communication, platform interaction, code quality and resilience, at defined verification levels. The companion testing guide describes how to verify each. I would use it as a checklist to scope mobile security testing rather than inventing one, choosing the level appropriate to the app, which for a banking application is materially higher than for a content app.

What they are assessing

A concrete and testable area.

Model answer

What is stored and where: the application sandbox, shared preferences, local databases, cached files and any external storage. Whether anything sensitive is in clear text, which is checked by inspecting the files on a rooted or jailbroken device or through a debug build. Whether credentials and tokens use the platform secure storage. Whether data is included in device backups, since that moves it off the device. And whether data is removed on logout, which is frequently incomplete and leaves the previous user data readable by the next.

What they are assessing

Release practice specific to mobile.

Model answer

Releasing to a small percentage of users first and increasing it gradually, available on both stores. It matters because mobile releases cannot be rolled back for users who have already updated, so limiting exposure is the main safety mechanism available. The testing relevance is that the rollout decision needs criteria: crash-free rate, ANR rate, review sentiment and key business metrics, monitored at each stage, with a defined threshold for halting. Without those criteria a staged rollout is just a slower release.

Likely follow-up

Why can a mobile release not simply be rolled back?

What they are assessing

Practical knowledge that prevents delays.

Model answer

On Apple, common causes are incomplete functionality or placeholder content, crashes during review, missing or inaccurate privacy disclosures, using private APIs, payment flows bypassing in-app purchase where it is required, and insufficient information for the review team to test the app, such as missing demo credentials. On Google the review is lighter but policy violations around permissions, data handling declarations and target API level requirements cause rejections. Verifying the privacy declarations match what the app actually does is a legitimate testing activity and is frequently nobody responsibility.

What they are assessing

Distribution channels for test builds.

Model answer

TestFlight distributes iOS builds to internal and external testers before release, with external testing requiring a review. Google Play offers internal, closed and open testing tracks with increasing audience size and decreasing control. Both are how beta testing happens at scale and both are also how a build is verified in the real distribution path, which matters because an app behaves differently when installed from the store than when side-loaded, particularly around signing, in-app purchases and some platform services.

What they are assessing

A product decision with testing implications.

Model answer

By testing the mechanism itself, which is usually a server-driven minimum version check that blocks the app and prompts the user to update. The cases to cover are a version below the minimum being blocked correctly, a version at the boundary, the prompt routing to the correct store listing, and the behaviour when the check itself fails, which must not lock everyone out. Alongside that is the question of how long old versions are supported, since the API has to keep serving them until the user base has moved, and testing against the oldest supported client is part of API regression.

What they are assessing

Tooling landscape.

Model answer

Appium is cross-platform, driving both iOS and Android through the WebDriver protocol with one API, which is its main appeal, at the cost of slower execution and more setup. Espresso for Android and XCUITest for iOS are the platform-native frameworks, substantially faster and more stable because they run in process with the app, but each covers one platform and tests are written in the platform language. Detox is aimed at React Native. Maestro is a newer, simpler declarative option. Appium mechanics specifically are covered in the Appium bank.

Likely follow-up

When would you choose the native frameworks over Appium?

What they are assessing

A genuine architectural decision.

Model answer

Native frameworks where the priority is speed and stability and the teams are platform-specific, because running in process removes a large class of flakiness and the tests are much faster, which matters when they run on every commit. Appium where one team covers both platforms, where the testers are not iOS and Android developers, or where the suite must also cover a mobile web or hybrid context. A common arrangement is native frameworks for the large fast layer owned by developers, and a small Appium suite for cross-platform end to end journeys owned by QA.

What they are assessing

Test placement.

Model answer

Less than teams usually assume. Business logic, API contracts and data handling are far better verified below the interface, at unit level within the app and at API level against the backend, where tests are fast and stable. Interface automation should cover the journeys where the interface itself is the risk, plus a smoke set. The specific mobile argument is that device-based interface tests are the slowest and most fragile tests available, so a suite of several hundred of them will not run on every commit and will absorb most of the team maintenance capacity.

Trap to avoid

Proposing to automate the full regression pass through Appium. The runtime and flakiness make it unworkable, and it is the most common reason mobile automation gets abandoned.

What they are assessing

Realistic boundaries.

Model answer

Much of the hardware interaction: camera input, biometrics beyond a simulated success, Bluetooth and NFC pairing, and real sensor behaviour. Genuine network conditions, though these can be approximated. The actual user experience, including whether something is reachable one-handed or readable in sunlight. Accessibility judgement, as distinct from mechanical checks. Store installation and purchase flows, partly. And manufacturer-specific battery management behaviour. All of those remain manual or require specialist equipment, which is why a mobile team cannot be automation-only.

What they are assessing

A practical constraint unique to installed apps.

Model answer

Through build variants or schemes that bake the endpoint into the build, which is the normal approach, or through a hidden developer menu in non-production builds that lets the environment be switched at runtime. The latter is more convenient for testing but must be impossible in a release build. The underlying difficulty is that an installed app cannot simply be repointed the way a browser can, so environment coverage requires separate builds, which has to be planned into the pipeline rather than improvised.

What they are assessing

A constraint with device-specific aspects.

Model answer

Mostly through the backend, creating accounts and data through APIs so the device is just a client. The device-specific part is the local state, which persists between tests and between runs, so a reliable approach needs the ability to reset the app to a known state: clearing app data on Android, reinstalling, or a debug-only reset function. For upgrade testing the opposite is needed, a library of preserved device states from earlier versions. Shared device labs also need accounts not being used concurrently by another tester.

What they are assessing

A practice with a mobile-specific wrinkle.

Model answer

By exercising both states, which is the same as anywhere, with the mobile-specific concern being that the flag is usually evaluated remotely and may change while the app is running or between launches. So the cases are flag on, flag off, and the transition while the app is open, which can leave the interface in an inconsistent state. Also important is the fallback when the flag service is unreachable, since the app must behave sensibly rather than hanging, and the default it falls back to should be deliberate.

What they are assessing

The primary mobile quality metric in production.

Model answer

The percentage of sessions or users that did not experience a crash, reported by tools such as Crashlytics and by the stores themselves. It matters because it is the single best proxy for mobile quality in the field, it is comparable between releases, and it is the main input to a staged rollout decision. A drop after a release is the clearest signal to halt. It needs reading alongside the ANR rate on Android, since an app that freezes rather than crashing can have an excellent crash-free rate and a terrible user experience.

Likely follow-up

What would make you halt a rollout other than crashes?

What they are assessing

Closing the loop.

Model answer

By treating each significant crash as a test gap rather than only as a defect. The report gives the device, operating system version, the stack and often the preceding user actions, which together usually explain why testing missed it: an unsupported device, a state nobody produced, or a condition such as low memory. The useful response is to add that device or condition to the matrix and a test for the scenario, so the class of defect is covered rather than the single instance. Over time the pattern of crashes also tells you whether the device matrix is wrong.

What they are assessing

Post-release responsibility.

Model answer

Crash-free rate and ANR rate against the previous version. Adoption rate, which tells you how much of the user base the figures represent. Key business funnels, since a release can be stable and still break conversion. App store reviews and rating trend, which surface issues no metric captures. Backend error rates filtered by client version, which catch problems the app reports as handled. And performance metrics such as start time. The first forty-eight hours matter most because that is the window in which halting a staged rollout is still useful.

What they are assessing

Hardware interaction.

Model answer

On real devices, since emulators cannot reproduce it meaningfully. The cases are permission granted, denied and permanently denied; capture, retake and cancel; using an existing image from the gallery as an alternative path; very large images and the resulting memory pressure; poor lighting where image quality affects any processing; orientation, since photographs carry rotation metadata that is frequently mishandled; and interruption during capture. Front and rear cameras and different device camera capabilities also produce different results.

What they are assessing

A sensitive feature with many failure paths.

Model answer

The success path on a real device, then the failure paths which matter more: an unrecognised biometric, repeated failures triggering lockout, falling back to a PIN or password, biometrics not enrolled on the device, biometrics disabled in app settings, and a new biometric being enrolled after the app was configured, which on both platforms should invalidate the stored key and force re-authentication. That last case is a genuine security requirement and is almost never tested. Simulators can trigger synthetic success and failure, which covers the logic but not the integration.

What they are assessing

A business-relevant quality attribute.

Model answer

Because install conversion falls as size rises, particularly on cellular connections and in markets where data is expensive, and because some users are at their storage limit. What to check is the download size and the installed size against the previous release, since unexplained growth usually means a dependency or uncompressed assets were added without anyone noticing. Both platforms provide tooling to break down the contents. Checking it per release makes a regression visible while it is still a single commit rather than a year of accumulation.

What they are assessing

Resource constraints that are easy to induce and rarely tested.

Model answer

By inducing them deliberately rather than waiting: filling device storage to near capacity and attempting operations that write, such as downloads, caching and image capture, and verifying the app reports the problem rather than failing silently or corrupting data. For memory, using the developer options to limit background processes, or opening many apps, then returning to see whether the app restores correctly after being terminated. Both conditions are common in the field, particularly on lower-specification devices, and both produce defects a well-resourced test device never sees.

What they are assessing

A feature that is widely supported and shallowly tested.

Model answer

A system-level appearance setting the app should honour. Testing covers every screen in both appearances, since an unstyled screen or component appears as dark text on a dark background. Images and icons with baked-in backgrounds, which look wrong in one mode. Contrast ratios, which need checking separately in each. Switching mode while the app is open, which should apply without restart and without losing state. And any screen that deliberately stays light, such as a document viewer, which should be a decision rather than an omission.

What they are assessing

A small, mobile-specific disclosure risk.

Model answer

That screens showing sensitive information are obscured in the task switcher snapshot, since both platforms capture the current screen when the app is backgrounded and that image is visible to anyone who picks up the device. Banking and health apps normally blur or cover it. Testing it means backgrounding from a sensitive screen and inspecting the switcher. It is a requirement in several security standards and is the kind of thing that is implemented for one screen and missed on three others.

What they are assessing

Understanding the release constraint.

Model answer

A fix released outside the normal cycle, which on mobile means a new build, store review, publication, and then users having to update, so even an expedited review takes hours and full adoption takes days or weeks. That is why mobile defects are more expensive than web defects of equal severity. The mitigations are server-side fixes where the behaviour can be changed from the backend, feature flags allowing a broken feature to be disabled remotely, and forced update mechanisms for the most serious cases. Having those available is a design decision made long before the incident.

What they are assessing

The maintenance problem.

Model answer

By minimising what runs through the interface, which is the single largest factor. Then by using accessibility identifiers as locators rather than text or structural paths, which requires developers to add them and is worth asking for. Then by establishing state through APIs rather than by navigating. Then by handling the device-level noise: permission dialogues, system popups and keyboard behaviour, which are a common source of failures unrelated to the test. And by running on consistent device configurations, since a suite spread across varied devices and versions will fail for environmental reasons and erode trust.

Likely follow-up

Why are accessibility identifiers the right locator strategy?

What they are assessing

An accessibility setting with visible consequences.

Model answer

The system text size setting, which users can increase substantially, and which apps are expected to honour. It breaks layouts because designs are built at the default size, so at the largest setting text overflows, truncates, or pushes controls off screen, and fixed-height containers clip their contents. It is one of the fastest ways to find layout defects: setting the largest text size and walking the app usually reveals several in minutes. It is also a legal requirement under accessibility regulation in several jurisdictions.

What they are assessing

Practical logistics.

Model answer

Through the platform mechanisms where possible, meaning TestFlight for iOS and the Play internal testing track for Android, because they exercise the real installation path and handle signing correctly. Firebase App Distribution is a common cross-platform alternative with simpler device management. Direct installation of an APK or an enterprise-signed IPA works for Android and for internal iOS distribution but behaves differently from a store install in ways that matter for purchases and some services. Build availability being automated from CI is what stops distribution becoming a bottleneck.

What they are assessing

A core diagnostic skill.

Model answer

With an intercepting proxy such as Charles, Proxyman or mitmproxy, configured as the device proxy with its certificate trusted on the device. On Android, recent versions do not trust user-installed certificates for app traffic by default, so a debug build with a network security configuration permitting it is needed. Certificate pinning prevents interception entirely and requires a build with it disabled. Being able to see the actual requests is what separates reporting the screen shows an error from reporting the API returned a 500 with this payload.

What they are assessing

Approach by app type.

Model answer

The web view content can largely be tested as web content, including with browser developer tools attached to the device, which is a significant advantage. What needs specific attention is the boundary: the bridge between the web view and native capabilities such as camera, storage and push, which is where hybrid apps break. Also the differences between the web view and a real browser, since the embedded engine may differ in version and capability from the device browser. And navigation, where the back action must be coordinated between the web history and the native stack.

What they are assessing

A permission-dependent feature with several states.

Model answer

Permission in each state including while in use, always, approximate rather than precise on recent versions, and denied. Location services disabled at the device level, which is different from permission denied. Poor accuracy and no fix available, where the app should degrade gracefully rather than hanging. Movement, since behaviour that works standing still can fail as the position updates. Background location, which is heavily restricted and is where battery complaints originate. And mock locations, which are how you test specific places without travelling.

What they are assessing

An underused feedback source.

Model answer

They surface problems no telemetry captures, particularly usability complaints and device-specific issues on handsets outside the test matrix, and they are the only channel where users describe the experience in their own terms. The practical use is monitoring for a spike after a release, which often precedes any metric moving, and categorising recurring themes into a backlog rather than responding individually. The caveat is strong selection bias toward people who are angry, so volume indicates trends rather than proportions.

What they are assessing

Calibration.

Model answer

The set of device and operating system combinations tested, derived from the user base. The size depends on what is being covered: a small set of perhaps four or five for the full regression pass, chosen to span the oldest supported version, the dominant configuration, a low-specification device and both platforms, with a wider set run less often for compatibility checking, which is where a device cloud earns its cost. Making it too large means nothing is tested properly; making it too narrow means defects reach the field on common devices.

What they are assessing

Diagnosis.

Model answer

By establishing what slow means and where, since app launch, screen transition, scroll and a specific operation are different problems with different causes. Then reproducing on a device matching the report, because a flagship will not show it. Then using the platform profiler to see where the time goes: main thread blocking, rendering, network or garbage collection. Network is the most common cause and is often a backend problem rather than an app one, which is why checking the API response time first frequently resolves it. Comparing against the previous version isolates whether it is a regression.

What they are assessing

A security behaviour with mobile-specific cases.

Model answer

The timeout applying while the app is backgrounded, which is the important case since users leave apps open for days. Re-authentication being required on return after the period, and that the screen beneath is not briefly visible before the lock appears. The token expiring mid-operation and whether the app refreshes transparently or fails. Device reboot, after which the session should behave according to policy. And that logging out actually clears the local session rather than only navigating away, which is verifiable by inspecting the stored data.

What they are assessing

A practical trade-off.

Model answer

Both, for different purposes. Emulators and simulators are cheap, fast to provision and parallelise well, so they suit the bulk of functional regression running on every build. Real devices are necessary for anything involving hardware, performance, battery, real network behaviour or manufacturer-specific behaviour, and for a final verification pass before release. The pragmatic arrangement is emulated for breadth and frequency, real for depth and confidence, rather than choosing one.

What they are assessing

A distinction that catches teams out.

Model answer

Release builds are optimised, obfuscated and have debugging disabled, which changes behaviour in ways that matter: code shrinking can remove classes referenced only by reflection, obfuscation breaks anything depending on class names, and certificate pinning and root detection are usually active only in release. Logging is typically stripped. So a suite that only ever runs against debug builds can pass while the shipping build crashes, which happens often enough to be a known category. A release-configuration build should be tested before every release.

Trap to avoid

Running the entire regression against debug builds. Obfuscation and shrinking defects appear only in the build that ships.

What they are assessing

A control with a judgement attached.

Model answer

Checks that the device has not been compromised, used to refuse to run or to restrict functionality, because a rooted device removes the platform security guarantees the app relies on. Whether every app needs it is a risk decision: it is expected in banking and payment apps and disproportionate for a content app, since it excludes legitimate users and can always be defeated by a determined attacker. Where it exists, testing means verifying it triggers on a rooted device and does not false positive on a normal one, which is the more common defect.

What they are assessing

A perspective often missing in well-resourced teams.

Model answer

By throttling to realistic conditions rather than testing on office WiFi, and measuring what the app actually consumes over a typical session, which is frequently far more than anyone expects because of unoptimised images, over-fetching and background polling. The behaviours to check are whether large downloads are deferred or ask for confirmation on a metered connection, whether images are sized for the device rather than downloaded at full resolution, and whether the app functions at all at low bandwidth rather than timing out. For products with users in markets where data is costly, this is a functional requirement rather than an optimisation.

What they are assessing

Practical investigation.

Model answer

By getting the specifics first: exact model, operating system version, app version, and the steps with a screen recording if possible, since mobile reports are usually vague. Then checking the crash reporting tool, which often has the stack and the preceding breadcrumbs. Then renting the device through a cloud provider, which is one of the strongest arguments for having access to one. If it is a manufacturer behaviour, an emulator will not reproduce it and the cloud device is the only route. If none of that works, adding targeted logging to a release and waiting for it to recur is a legitimate last resort.

What they are assessing

A technique with a narrow but real value.

Model answer

Automated random input at high volume, available as a built-in tool on Android, which fires taps, swipes and system events indiscriminately. It is useful for finding crashes from unexpected input sequences and for stability soak testing, and it occasionally finds genuine defects no designed test would reach. It is not a substitute for designed testing, since it verifies nothing and reports only crashes, and its findings are sometimes states a real user could not reach. I would run it as a periodic stability check rather than as part of the regular pass.

What they are assessing

Capability design.

Model answer

Device access first, since without the right devices nothing else is credible: a small owned set for daily work plus cloud access for breadth, chosen from analytics. Then the fundamentals that prevent the worst defects: upgrade testing, interrupt and lifecycle testing, and permission states, none of which need automation. Then automation below the interface, meaning unit tests in the app and API tests against the backend, before any device automation. Then a thin interface suite on the critical journeys. And crash reporting with a staged rollout process from the first release, because production feedback is the strongest signal available on mobile.

Likely follow-up

Why would you build device automation last rather than first?

What they are assessing

Operating the main mobile safety mechanism.

Model answer

Against criteria agreed in advance rather than in the moment, because under pressure the bias is always to continue. The usual thresholds are a crash-free rate falling below a stated figure relative to the previous version, an ANR rate rising, a key funnel metric dropping, or a serious defect reported regardless of volume. The subtlety is that early rollout data is noisy on small samples, so the thresholds need to account for the population size at each stage. Having the criteria written down is what makes halting a decision rather than an argument.

What they are assessing

A requirement with a clear test method.

Model answer

The app returning the user to where they were after being backgrounded and terminated, rather than restarting at the home screen. Testing it means navigating deep into the app with some unsaved state, backgrounding, forcing the process to be killed, and returning. The correct behaviour is restoring the screen and the data. The common failures are returning to the first screen, crashing because state is missing, or appearing to restore while the underlying data was lost. It is one of the highest-value mobile tests and routinely absent from test plans.

What they are assessing

Annual risk that is predictable and often unplanned for.

Model answer

Typically the permission model tightens, background execution becomes more restricted, privacy requirements increase, some APIs are deprecated and a minimum target version becomes mandatory for store updates. The practical effect is that an app working perfectly can break for users who upgrade, and since adoption on iOS is rapid, a large proportion of the user base moves within weeks. The response is testing against the beta during the preview period and treating the annual release as a planned regression cycle rather than an event to react to.

What they are assessing

Release judgement with mobile-specific weighting.

Model answer

With more caution than for web, because the release cannot be withdrawn from users who have taken it and a fix takes days to reach them. So the bar is higher: regression passed on the core matrix, no open defects above the agreed severity, upgrade path verified from supported previous versions, the release-configuration build tested rather than a debug build, and store requirements such as privacy declarations verified. Then a staged rollout with defined halt criteria, which is the real safety net and should be treated as part of the release rather than as an optional extra.

What they are assessing

Commercial argument.

Model answer

By showing what is not covered without them, using production crash data broken down by device and operating system, which usually demonstrates that a meaningful share of crashes occur on configurations nobody tests. Then the cost of a store release cycle to fix something that would have been caught, which on mobile includes review time and slow adoption. Framing it against the revenue or usage attributable to the affected segment makes it concrete. Arguing for device coverage as good practice without that evidence rarely succeeds.

What they are assessing

A synthesising question.

Model answer

The combinatorial surface. Device, operating system version, manufacturer layer, screen size, network condition, permission state, app lifecycle state and upgrade path all multiply, and no realistic test effort covers the product of them. So mobile testing is more about choosing a small, well-reasoned subset than about coverage, and the subset has to be derived from real usage data rather than from intuition. The second difficulty is that the consequence of missing something is higher, because the fix cannot be deployed in an hour, which changes how much verification is proportionate.

What they are assessing

A closing question revealing depth of experience.

Model answer

Testing the app as if it were a website on a small screen. The team covers the functional journeys on a current device on good WiFi with permissions granted and a fresh install, and misses everything that makes mobile different: upgrade from the previous version, which is what most users actually do, interrupts and process death, permission denial, poor and changing connectivity, and low-specification devices. Those are where the field defects come from, they are cheap to test, and they are absent from most test plans because none of them are features anyone wrote a story for.