[{"data":1,"prerenderedAt":22},["ShallowReactive",2],{"blog-post-en-run-smoke-tests-multiple-android-devices-phoma":3},{"slug":4,"lang":5,"title":6,"summary":7,"date":8,"tags":9,"tag_slugs":14,"thumbnail_url":18,"translations":19,"body":20,"asset_base":21},"run-smoke-tests-multiple-android-devices-phoma","en","Run Smoke Tests on Multiple Android Devices with Phoma’s Visual Flow Builder","Discover how to create a single smoke‑test flow in Phoma and execute it across dozens of Android phones, using visual element selection, scheduling, and team sharing.","2026-11-03",[10,11,12,13],"phoma","android automation","smoke testing","mobile qa",[10,15,16,17],"android-automation","smoke-testing","mobile-qa","https://blog-api.phomaapp.com/api/blog/posts/run-smoke-tests-multiple-android-devices-phoma/thumbnail.svg?lang=en",[5],"## Why Visual Automation Works for Smoke Testing\n\nSmoke tests are the first line of quality assurance for any Android app. They verify that the core user journeys—login, data entry, navigation—still work after each build. Traditional approaches require writing scripts in Appium, Espresso, or UI Automator, which can be time‑consuming and fragile when UI changes.\n\nPhoma’s visual flow builder lets you design these smoke tests without a single line of code. By building a flow once and then running it on many devices, you get fast feedback, consistent execution, and a clear audit trail. The visual nature also makes it easy for non‑technical team members to contribute to test maintenance.\n\n## Connect Your Android Phones to Phoma\n\nBefore you can run a flow, Phoma must see the devices. You have two common connection methods:\n\n### USB Debugging\n1. Enable Developer Options on each phone (Settings → About → Build number, tap 7 times). \n2. In Developer Options, turn on **USB Debugging**. \n3. Connect the phone to your Windows PC with a USB cable. \n4. On the PC, open Phoma and click **Add Device**. Phoma will install the necessary drivers automatically (Windows Driver Installer runs silently). \n5. When prompted, confirm the debugging trust on the phone.\n\n### Wireless Debugging (Wi‑Fi)\n1. Keep USB debugging enabled for the initial pairing. \n2. On the phone, go to **Developer Options** → **Wireless Debugging** and turn it on. \n3. The PC will show a QR code or pairing code—scan it with the phone or enter the code manually. \n4. After pairing, disconnect the USB cable. Phoma will list the device under **Wireless** tab.\n\nIf a device never appears, check that the USB driver is up‑to‑date, that the phone’s OEM allows debugging (some manufacturers lock it), and that Windows Firewall isn’t blocking adb. Restarting Phoma and the phone often resolves connection hiccups.\n\n## Build a Smoke‑Test Flow in Phoma\n\nOpen Phoma and click **New Flow**. Give the flow a descriptive name like `Login Smoke Test`. The canvas shows a step list; start with the first action.\n\n### 1. Launch the App\n- Drag **Open App** from the palette. \n- In the **Package** field, type `com.example.myapp`. \n- In **Activity**, leave blank to start the main launcher activity. \n- Click **Add Step**.\n\n### 2. Wait for the Login Screen\n- Add a **Wait for Element** step. \n- Choose the selector type. Phoma offers three robust options:\n\n```text\n1. Accessibility ID – `resource-id=\"com.example.myapp:id/login_button\"`\n2. Class Name – `className=\"android.widget.Button\"`\n3. Text – `textContains=\"Sign In\"`\n```\n\nPick **Accessibility ID** if the element has a stable `content-desc`. If the app doesn’t set it, fall back to **Class Name** and combine with **Text** for uniqueness.\n\n- Set **Timeout** to 5 seconds. Click **Add Step**.\n\n### 3. Enter Credentials\n- Add a **Type Text** step. \n- Bind it to the username field (`resource-id=\"com.example.myapp:id/username\"`). \n- Input `testuser`. \n- Add another **Type Text** for the password field (`resource-id=\"com.example.myapp:id/password\"`) with `secretText=\"true\"`. \n- Input `TestPass123`.\n\n### 4. Tap the Sign‑In Button\n- Add a **Tap** step targeting the same login button used earlier.\n- Set **Duration** to 0.2 seconds for a quick tap.\n\n### 5. Verify Successful Navigation\n- Add a **Wait for Element** for the home screen (`resource-id=\"com.example.myapp:id/home_title\"`). \n- If the element appears, the flow continues; otherwise, it stops and marks the step as failed.\n\n### 6. Capture Evidence\n- Insert a **Screenshot** step. \n- Name it `login_success.png`. This screenshot is saved to the phone’s storage and attached to the run log.\n\n### 7. (Optional) Perform a Simple Assertion\n- Use **Read Text** on the home title element, then a **Assert Text** step. \n- Example: `Assert Text equals \"Welcome\"`. This adds a deterministic pass/fail signal without writing code.\n\nSave the flow. At this point you have a reusable smoke‑test that can be edited later without breaking existing runs.\n\n## Selecting Elements That Survive App Updates\n\nUI changes are inevitable. To future‑proof your flow:\n\n- **Prefer Accessibility IDs** whenever the app sets them; they are less likely to be renamed than resource IDs. \n- Use **Class + Text** combinations: `className=\"android.widget.EditText\"` + `textContains=\"Username\"`. Even if the resource ID changes, the edit text with that label stays.\n- Avoid hard‑coded indices (e.g., `listItem[0]`). Instead, wait for a unique element within the list.\n- After each app update, run the flow on a single device. Phoma will show which step failed; you can then adjust the selector using the **Element Picker**—a visual overlay that highlights matching nodes in real time.\n\n## Run the Flow on Many Phones at Once\n\nPhoma’s **Batch Run** feature makes it trivial to execute the same flow on multiple devices:\n\n1. In the Flows list, select your smoke‑test flow. \n2. Click **Run** → **Batch Run**. \n3. Choose **Devices** and tick each phone you want to test. \n4. Toggle **Run in Parallel** (default) to start all devices simultaneously. \n5. Set a **Start Delay** (e.g., 2 seconds) to avoid thundering‑herd issues on Wi‑Fi networks. \n6. Click **Start**.\n\nEach device runs the flow independently, logging results to its own run history. The **Runs** view aggregates outcomes: you see a green check for devices that passed, red X for failures, and a link to the screenshot for each failed step.\n\n## Schedule Automated Smoke Tests\n\nFor continuous integration, schedule runs at specific times or after each build:\n\n- Open the flow, click the **Schedule** icon (clock). \n- Define a **Cron‑like schedule**: e.g., `0 9 * * 1-5` (weekdays at 9 AM). \n- Choose **Time Zone** matching your team’s location. \n- Select the target device group (or all devices). \n- Enable **Notify on Failure** and add an email or Slack webhook.\n\nScheduled runs respect the phone’s power state; Phoma will wake the device, run the flow, and then put it back to sleep, minimizing battery drain.\n\n## Share Flows and Devices Within a Team\n\nIf you need collaborative maintenance, upgrade to Phoma’s **Team** plan. Steps:\n\n- In Phoma, go to **Team** → **Share Flow**. \n- Enter team members’ email addresses. \n- Set permissions: **Edit** (full control) or **Run** (execute only). \n- For devices, use **Device Groups** to bundle phones by environment (e.g., “QA Lab”, “Staging”). \n- Members can now view, copy, or modify shared flows without overwriting the original.\n\nVersioning is implicit: each edit creates a new snapshot, and you can roll back to a previous version if a change introduces regressions.\n\n## Troubleshooting Common Issues\n\n| Symptom | Likely Cause | Quick Fix |\n|---------|--------------|-----------|\n| Device never appears | USB debugging disabled or driver missing | Re‑enable debugging, reinstall Windows driver via Phoma’s **Device Manager** tab |\n| Flow fails at **Wait for Element** | Selector outdated after UI change | Open **Element Picker**, select a new matching element, update selector |\n| Batch run stops early | One device runs out of battery | Ensure devices are charged; add a **Power Check** step before critical actions |\n| Scheduled run doesn’t start | Phoma service not running or Windows sleep mode | Set Windows to keep Phoma running as a background service; disable “Let Windows turn off devices to save power” for the PC |\n\nIf a flow repeatedly fails, capture a **Debug Run**: Phoma records the exact screen content and element tree for each step. Compare this with the live app to spot mismatches.\n\n## Best Practices for Reliable Smoke Tests\n\n- **Keep flows small** (≤ 10 steps). Smaller tests are easier to read, maintain, and debug. \n- **Use explicit waits** (`Wait for Element`) rather than `Sleep` nodes; they adapt to network latency. \n- **Capture screenshots** after each critical action; visual evidence speeds up root‑cause analysis. \n- **Avoid complex gestures** (e.g., multi‑finger swipes) unless you have a fallback selector. \n- **Document the purpose** of each step in the flow’s description field; this helps new team members understand intent.\n- **Run a smoke test on a fresh device** before committing to a schedule; this ensures the flow works on a clean install and with varied OS versions.\n\nBy following these practices, you’ll get consistent smoke‑test results across your device fleet, reduce manual QA overhead, and keep your app’s quality high.\n\n## Conclusion\n\nPhoma’s visual flow builder turns multi‑device smoke testing into a drag‑and‑drop experience. You can connect phones via USB or Wi‑Fi, design robust element selectors, and run the same flow on dozens of devices in parallel or on a schedule. Team sharing lets QA, developers, and operations collaborate without code, while built‑in troubleshooting tools keep failures visible and actionable.\n\nStart by creating a single login smoke test as outlined above. Scale it out to your whole testing lab, and watch your feedback loop tighten—without writing a single line of automation script.\n\n---\n*Ready to automate your smoke tests? Download Phoma today and import the sample flow used in this guide.*\n","https://blog-api.phomaapp.com/api/blog/posts/run-smoke-tests-multiple-android-devices-phoma/assets",1793695685558]