Automation

AI Prompts for Planning Appium Mobile Automation

Most flaky Appium suites are planning problems: brittle XPath locators, fixed sleeps, and one page object per test. Use this prompt before writing code to get a structured automation plan you can review with your team.

The prompt

You are a mobile SDET planning Appium automation.

App: [app name, native / hybrid / React Native / Flutter]
Platforms: [Android versions, iOS versions]
Language & runner: [e.g. Java + TestNG, Python + pytest, WebdriverIO]
Flow to automate:
[PASTE MANUAL TEST STEPS]

Produce an automation plan, not a finished framework:
1. Screens involved and a Page Object for each, listing elements and user actions as methods.
2. Locator strategy per element in priority order: accessibilityId, resource-id (Android) / name (iOS), then predicate/UiAutomator, XPath only as last resort. Note where developers should add accessibility IDs.
3. Waits: explicit wait conditions for each step; no fixed sleeps.
4. Android vs iOS differences in this flow (permissions dialogs, keyboard, back navigation, alerts).
5. Test data and app state setup/teardown.
6. Assertions per step and what evidence to capture on failure (screenshot, page source, logs).
7. A short code skeleton for ONE page object in [language], clearly marked as untested.

Do not claim the code has run.

Replace every [BRACKETED] placeholder with your own details.

Sample input: add item to cart (Android + iOS)

Fictional example written for this guide.

App: ShopLite, React Native
Platforms: Android 12–14, iOS 16–17
Stack: Java + TestNG + Appium 2 (UiAutomator2 / XCUITest)
Manual steps:
1. Launch app, allow notifications
2. Search "running shoes"
3. Open first result
4. Select size 42
5. Tap "Add to cart"
6. Verify cart badge shows 1

Sample AI output (illustrative, untested skeleton)

Sample output only — this shows the shape of a good answer. It has not been run, executed, or verified against a real system.

Page Objects: HomeScreen, SearchResultsScreen, ProductScreen, CartBadge (component)

ProductScreen
- sizeOption(size)   → accessibilityId "size-<n>"   (ask devs to add testID)
- addToCartButton    → accessibilityId "add-to-cart"
- methods: selectSize(int), addToCart()

Waits
- After search: wait until first result is visible (max 10s)
- After addToCart: wait until cart badge text equals "1"

Android vs iOS
- Notification prompt: Android 13+ system dialog vs iOS alert → handle via capability autoGrantPermissions (Android) / autoAcceptAlerts (iOS) or a dedicated handler

// UNTESTED SKELETON
public class ProductScreen {
  private final AppiumDriver driver;
  private final WebDriverWait wait;
  public ProductScreen(AppiumDriver driver) {
    this.driver = driver;
    this.wait = new WebDriverWait(driver, Duration.ofSeconds(10));
  }
  public void selectSize(int size) {
    wait.until(ExpectedConditions.elementToBeClickable(
      AppiumBy.accessibilityId("size-" + size))).click();
  }
  public void addToCart() {
    driver.findElement(AppiumBy.accessibilityId("add-to-cart")).click();
  }
}

Locator strategy, best to worst

LocatorAndroidiOSNotes
accessibilityIdcontent-descaccessibilityIdentifierFast, cross-platform; ask devs to add testIDs
id / nameresource-idnameStable if not auto-generated
Native queryUiAutomator selectorPredicate string / class chainGood for dynamic lists
XPathSupportedSupportedSlowest and most brittle — last resort

Page Object Model suggestions

  • One class per screen; shared widgets (tab bar, toasts) as components.
  • Methods describe user intent (addToCart) — never expose raw locators to tests.
  • Keep assertions in tests, not in page objects, except for “screen is loaded” checks.
  • Hold platform-specific locators in one place so tests stay platform-agnostic.

Waits and validation tips

  • Replace Thread.sleep with explicit waits on visibility, clickability, or text.
  • Keep implicit wait at 0 when using explicit waits to avoid compounded timeouts.
  • Reset app state between tests (noReset / fullReset) deliberately, not by default.
  • Capture screenshot + page source on failure; they make flaky failures diagnosable.
  • Validate on at least one real device per platform before trusting emulator results.

QA review before you use the output

  • • Check every capability and API name against the Appium 2 docs — AI often mixes v1 syntax.
  • • Run the skeleton on a device before committing; the AI has not executed it.
  • • Strip internal bundle IDs, build URLs, and credentials before pasting into a public AI tool.
  • • AI output can be wrong or incomplete. A human tester owns the final result.

Related prompts

Need a different QA prompt?

Browse 50+ copy-ready prompts or build your own in seconds.