Sample questions
Mq Mobile Locators Sync FlakinessDifficulty 1
In an Android UI Automator dump, what does an element's resource-id attribute correspond to in the app's source?
- aThe view's
android:id value, shown with the app's package prefix, e.g. com.example.app:id/submit_button✓ - bThe view's on-screen pixel coordinates at the moment the UI dump was captured
- cThe accessibility label a screen reader would announce for that view
- dA random hash Appium generates fresh for every test run to keep locators unique
Explanation:resource-id is populated from the view's android:id (or the id assigned in code), reported with the package prefix in the accessibility/UI Automator dump. On-screen coordinates are a separate bounds attribute, not resource-id. A screen-reader label maps to content-desc, a different attribute entirely. Appium does not fabricate resource-id values; it only reads what the app already exposes.
Mq Mobile Locators Sync FlakinessDifficulty 2
Using Appium's -android uiautomator strategy, which line correctly targets a view by its exact visible text with UiSelector?
- anew UiSelector().label("Sign in")
- bBy.text("Sign in")
- cnew UiSelector().text("Sign in")✓
- dnew BySelector().text("Sign in")
Explanation:UiSelector is the fluent Java builder evaluated inside an -android uiautomator string, and .text(...) matches the exact visible text. .label(...) is not a UiSelector method — label is iOS/XCUITest terminology, not part of Android's UiAutomator API. By is the separate instrumented-test class (UiDevice.findObject(By.text(...))), not something you construct inside the -android uiautomator string. BySelector likewise isn't instantiated with new and chained like UiSelector.
Mq Mobile Locators Sync FlakinessDifficulty 1
On iOS, what does Appium's accessibility id locator strategy actually match against?
- aThe element's visible label text, which is translated per locale
- bA name Xcode auto-generates from the Swift variable name of the UI control
- cThe element's
accessibilityIdentifier, a non-localized value set purely for automation tooling✓ - dA value that only exists on elements which also expose a
value, such as text fields and sliders
Explanation:accessibility id maps to accessibilityIdentifier, a developer-assigned, non-localized identifier meant specifically for test/accessibility tooling. Visible label text is a different property (label) and does change with locale. Xcode does not auto-generate identifiers from variable names; they must be set explicitly. accessibilityIdentifier is independent of whether an element has a value — buttons and labels can carry it too.
Mq Mobile Locators Sync FlakinessDifficulty 2
On iOS, what is the core difference between an element's label and its value as seen through XCUITest/Appium?
- a
label and value are two interchangeable names for the exact same string on every element type - b
label describes what the element is (often localized wording), while value reflects its current state or content✓ - c
value always holds the element's accessibilityIdentifier, while label holds an internal memory address - d
label only exists on buttons, and value only exists on images
Explanation:XCUITest exposes label (what the element is/says) and value (its current state or content) as distinct properties — a switch's label might be "Wi-Fi" while its value is "1" or "0". They are not aliases of each other. value does not hold the identifier — that is a separate identifier/accessibilityIdentifier property. Neither property is restricted to only buttons or only images.
Mq Mobile Locators Sync FlakinessDifficulty 2
Why does locating an element by its content-desc (Android) or label (iOS) tend to be more fragile than locating it by a dedicated test identifier?
- aTranslation teams localize it along with the visible UI text, so an exact-string locator breaks in another language✓
- bBecause Appium regenerates its value randomly on every single app launch for security reasons
- cBecause it is stripped from every release build regardless of any build configuration
- dBecause it only exists in debug builds and is compiled out of every release APK/IPA
Explanation:content-desc/label exist to serve accessibility, so they carry the same localized wording a screen-reader user hears — translating the app for a new market changes that string, breaking any locator hardcoded to it. Appium does not randomize these values. Neither content-desc nor label is a debug-only construct removed from release builds; both remain present as long as the developer set them.
Mq Mobile Locators Sync FlakinessDifficulty 2
Why is an XPath lookup typically much more expensive on mobile than locating the same element by a dedicated attribute like resource-id or accessibility id?
- aXPath queries are billed per character by the mobile OS vendor, so long expressions cost proportionally more
- bThe driver must serialize the whole accessibility tree and walk it node by node, so cost scales with tree size✓
- cXPath is a deprecated protocol that mobile operating systems actively throttle to discourage its use
- dXPath always requires a network round-trip to a cloud device farm, even when testing entirely on a local emulator
Explanation:XPath evaluation needs a full tree to walk, so the driver serializes the whole current hierarchy first — a deep or large screen makes every XPath lookup slower, independent of where the target sits. There is no per-character billing by an OS vendor for XPath. XPath is not throttled or deprecated by Android/iOS. XPath evaluation happens entirely on-device/in-driver and has nothing to do with cloud network round-trips.