Your Mobile QA Team Is Still Writing XPath. In 2026.

The Test That Breaks Every Sprint

You know the drill. Your QA engineer writes a beautiful test suite. Login, browse catalog, add to cart, checkout. Fifty selectors, careful waits, retry logic for flaky network calls. It passes on Monday.

Tuesday, the design team moves the checkout button. Three selectors break. The test fails. The QA engineer spends half a day updating locators. The test passes again.

Wednesday, a new feature adds a bottom sheet that overlaps the cart icon. The tap lands on the sheet instead of the cart. The test fails. Another half day.

This cycle repeats every sprint, in every mobile team, everywhere. The test suite doesn't test the app anymore — it tests whether the selectors still match the UI.

Selectors Were Never the Right Abstraction

XPath, resource IDs, accessibility identifiers — they're all addresses. "Tap the element at this path in the view hierarchy." The moment the hierarchy changes, the address is wrong.

Humans don't navigate apps by address. They look at the screen, see "Checkout," and tap it. They don't care that the button moved from one container to another. They just see the button and tap it.

AI agents can do the same thing — if you give them the screen, not a selector tree.

What "Giving Them the Screen" Looks Like

When an AI agent connects to Drengr, it asks: "What's on screen?" Drengr responds with a compact text description:

[1] "Checkout" (Button)
[2] "Your Cart: 3 items" (TextView)
[3] "Remove" (Button)
[4] "Continue Shopping" (Button)

Or an annotated image with numbered elements. The AI reads this, decides "tap element 1," and calls drengr_do. After the action, it gets a situation report telling it what changed.

No selectors. No XPath. No element IDs to maintain. The AI sees the screen the way a human does — by what's visible, not by where it lives in the view tree.

"But What About Reliability?"

Fair question. If the AI is interpreting the screen every time, doesn't that introduce non-determinism?

Yes. And that's the point. A deterministic test that breaks when the UI changes isn't reliable — it's rigid. An AI agent that adapts to UI changes is more reliable in practice because it handles the variations that break selector-based tests.

Drengr adds guardrails:

• Stuck detection — if the screen doesn't change after an action, the agent knows to try something else
• Crash detection — if the app dies, the agent knows immediately and can restart
• Situation reports — after every action, the agent gets a structured diff of what changed, so it stays oriented

The AI doesn't just blindly tap. It observes, acts, and adapts. That's more robust than a fixed script that works exactly one way.

The Cost Argument

"AI calls are expensive." Sure, if you're sending screenshots every step.

Drengr's text-only mode compresses a screen to ~300 tokens. A 15-step test flow costs about $0.05 on current LLM pricing. The same flow with screenshots costs $0.45.

But here's the real cost comparison: how much does your QA team spend maintaining selectors? If one engineer spends 2 hours a week updating broken tests, that's thousands per month in salary going to XPath maintenance. The AI API costs are rounding errors next to that.

A Test Suite That Survives Redesigns

app: com.example.shop
tasks:
  - name: browse
    task: "Search for wireless earbuds and open the first result"
    timeout: 60s
  - name: purchase
    task: "Add to cart and complete checkout with the test card"
    timeout: 90s
  - name: verify
    task: "Go to order history and verify the order appears"
    timeout: 45s

This YAML survived 3 redesigns of our test app. The checkout flow moved from a separate page to a bottom sheet to a full-screen modal. The YAML didn't change. The AI adapted every time because it reads the screen, not the selectors.

drengr test tests.yml runs it. JUnit XML output plugs into any CI pipeline. No Appium server to maintain, no Selenium grid, no element locator spreadsheet.

One Binary. One Install.

Drengr runs on real Android phones, iOS simulators, and cloud device farms (BrowserStack, SauceLabs, AWS Device Farm, LambdaTest, Perfecto, Kobiton). It connects to any MCP-compatible AI client — Claude Desktop, Cursor, Windsurf, VS Code.

npm install -g drengr

Your QA team can stop writing XPath. The AI can read the screen.