A4Q Foundation Level Tester for Appium common mistakes
A4Q Foundation Level Tester for Appium · Understand the traps and how to avoid them.
Treating Appium's W3C/JSONWP session capabilities as interchangeable and assuming any capability name works on any driver version, e.g. passing `automationName` values or legacy-only capabilities to a driver that has dropped them.
Candidates memorise a capability list from one older tutorial and do not check which protocol (W3C WebDriver vs legacy JSON Wire Protocol) and which driver version they are targeting, so they pick options that are silently ignored or rejected at session creation.
What to do instead
Learn the capability negotiation model: distinguish standard W3C capabilities from Appium-specific extensions, know that vendor extensions live under appium:-prefixed names in W3C mode, and practice starting sessions against the specific driver (UiAutomator2, XCUITest, etc.) to see which capabilities are honoured.
Confusing implicit and explicit waits, or mixing them (setting a global implicit wait and also using WebDriverWait), then diagnosing flakiness as an Appium bug.
Candidates carry over Selenium habits and add sleeps or long implicit waits as a blanket fix, without understanding that implicit waits apply per element lookup and interact badly with explicit conditions and with pageLoadTimeout/newCommandTimeout.
What to do instead
Be able to state what each timeout controls: newCommandTimeout (driver-side idle session timeout), implicit wait (per find), explicit wait (per condition), and pageLoadTimeout. Practise replacing Thread.sleep with expected conditions and know why combining implicit and explicit waits is discouraged.
Using XPath or CSS selectors as the default locator strategy on native apps, or writing locators that depend on absolute hierarchy paths and index positions.
Candidates come from web automation where XPath/CSS is normal, and they do not realise native contexts expose accessibility IDs, resource IDs, and platform-specific predicates/class chains that are faster and more stable than deep XPath.
What to do instead
Learn the locator strategies per platform: accessibility id, id/resource-id, class name, -android uiautomator and -ios predicate string/-ios class chain, and know when XPath is genuinely required. Prefer accessibility ids and test tags, and avoid index-based or absolute-path selectors.
Forgetting to switch context when automating hybrid apps, or switching to a WEBVIEW context without waiting for it to appear, so element lookups fail or hit the wrong DOM.
Candidates test the native shell and the web content as if they were one context; they also do not know that the webview context only becomes available after the page loads and may need setWebContentsDebuggingEnabled on Android or the appropriate XCUITest/webview setup on iOS.
What to do instead
Know the context API (getContextHandles, getContext, setContext) and that you must switch back to NATIVE_APP for native elements. Practise waiting for the webview context to be listed before switching, and know the platform prerequisites for debugging webviews.
Assuming the same test code and locators run unchanged across Android and iOS, then blaming Appium when iOS locators fail on Android.
Appium's cross-platform promise is about the API, not about identical UI hierarchies; candidates underestimate platform differences in element classes, accessibility mapping, and system behaviours (back button vs swipe, permission dialogs).
What to do instead
Design for platform abstraction: page objects per platform behind a common interface, platform-conditional locators, and separate handling of navigation and permission prompts. Be able to explain which parts of a test are genuinely portable and which are platform-specific.
Hard-coding device and platform details (UDID, platform version, app path, device name) directly in test code or in a single capabilities block.
Candidates build one working local session and stop, so the suite only runs on their machine/emulator; they do not separate configuration from test logic and do not know how capabilities are supplied at runtime.
What to do instead
Externalise capabilities into config files or environment variables, use a capabilities-builder pattern, and practise running the same tests against a different device/emulator by changing configuration only. Understand noReset/fullReset and app install/reset behaviour as configuration decisions.
Ignoring the difference between app states (installed, running, backgrounded, reset) and using `noReset`/`fullReset` without knowing their effect, leading to tests that pass locally and fail in CI.
Candidates treat app installation as automatic and never reason about leftover state, logged-in sessions, or permissions granted by a previous run, so test order and prior runs change outcomes.
What to do instead
Learn what each reset-related capability and driver command does (install, launch, terminate, activate, background, reset), and design tests that are independent of prior state. Verify behaviour by running a test twice in a row and after clearing app data.
Treating gestures as fixed coordinates or using deprecated TouchAction-style APIs rather than the current W3C actions model, so tests break across screen sizes and driver versions.
Candidates copy older swipe/scroll snippets with absolute pixel values and do not learn that pointer input is now expressed as W3C action sequences; they also ignore device pixel ratio and element-relative positioning.
What to do instead
Understand the W3C actions API (pointer, key, pause) and how to build taps, swipes, long-press, and multi-touch from it. Prefer element-relative coordinates or platform scroll commands, and know when to use driver-provided helpers versus raw actions.
Writing tests that only assert on element presence and then claiming coverage of mobile-specific behaviours such as notifications, interruptions, network changes, or rotation.
Candidates map web testing patterns onto mobile without addressing the mobile-specific risk areas the syllabus calls out, and they do not know the Appium commands/APIs available for device interaction.
What to do instead
Study mobile-specific test scenarios: orientation change, backgrounding, incoming calls/notifications, network conditions, and permission dialogs. Know the relevant APIs (e.g. orientation, background app, network/connection settings, lock/unlock) and build assertions around observable app state, not just element existence.
Misreading the exam's framing of Appium's architecture - e.g. claiming Appium is a wrapper around Selenium that drives apps directly, or that it requires app modification/instrumentation for all platforms.
Candidates learn commands without the client-server model, so they cannot answer conceptual questions about the Appium server, drivers/plugins, sessions, and how commands are proxied to platform automation frameworks.
What to do instead
Be able to describe the flow: client library sends W3C commands over HTTP to the Appium server, which routes them to the appropriate driver, which uses the platform's automation framework. Know what is and is not required per platform (e.g. UiAutomator2 vs XCUITest vs webview debugging) and why no app recompilation is needed for standard automation.