•

Drizz raises $2.7M in seed funding •

•

Featured on Forbes

•

Drizz raises $2.7M in seed funding •

•

Featured on Forbes

Logo

Schedule a demo

Blog
>
A Practical Benchmark for Vision-Based Mobile Test Automation

A Practical Benchmark for Vision-Based Mobile Test Automation

Comparing UI-TapBench vs. other existing benchmarks. Understanding what matters when measuring mobile automation at the tap level and why tap-level precision is vital to mobile CI/CD.
Author:
Asad Abrar
Posted on:
October 22, 2026
Read time:
10 mins

Most mobile testing tools break when they have to interact with a complicated app flow. Mobile AI and automation tools are often able to understand and interact with screens and elements, only to tap buttons 40 pixels away from the actual element.

With mobile testing, precise interaction matters. The AI Agent has to understand, locate, and interact with the screen element. Wrong clicks also invalidate all the subsequent interactions. The app could open the wrong screen and make the rest of the test yield incorrect results.

For this reason, we do not consider general model intelligence as sufficient evidence of practical CI/CD capability. We also evaluate how well an AI Agent is able to carry out the task after understanding the screen.

To measure the performance of mobile UI and interaction automation systems, we can give a model a screenshot and a tapping instruction, and see if the model can tap where it should.

In this guide, we discuss what matters when measuring mobile automation at the tap level, why tap-level precision is vital to mobile CI/CD, and how UI-TapBench measures performance across 570 screenshots of 20 production apps. It also highlights the difference between understanding a mobile interface and interacting with it reliably.

Why tap accuracy matters in mobile CI/CD

A test flow typically has 15 to 20 individual actions. Each action introduces the chance for failure. An AI agent that achieved 95% accuracy for each tap would have a 46% chance of completing a 15-step flow with no errors.

Claims of “agent x understands app y” have diminishing returns. The impact of small drops in accuracy of each tap decreases along with the number of flows completed.

Incorrect taps create noisy results. If the third action in our test flow opens the incorrect screen, the next 12 assertions may fail, even though the application has no 12 separate defects. The failure occurs as a result of a single, incorrect action.

Automation that takes work to maintain does not provide any benefits as a result of a fast release pipeline. The goal should be to remove obstacles.

What UI-TapBench Measures

UI-TapBench measures the ability to perform precise taps on the mobile UI. Each benchmark provided includes the following:

  • An image of the mobile app
  • An English text instruction
  • A target region superimposed on the image
  • Location coordinates of the target region

The model is presented with the image and the text instruction, and predicts the tap location. A prediction is considered correct if it falls within the target region.

This design simplifies the more complex variables in mobile agent benchmarks and does not measure long-term planning, app state management, API calls, or recovering after a failed action. Instead, the goal is to know if the model clicked on the correct image.

The benchmark consists of 570 screenshots gathered from 20 production applications in the areas of food delivery, travel, communication, entertainment, finance, health, education, productivity, and other apps such as Uber Eats, Airbnb, WhatsApp, Spotify, Netflix, Duolingo, PayPal, Strava, Notion, and Todoist.

The applications include the conditions in which visual agents encounter challenges:

  • Dense lists with similar rows
  • Nested menus
  • Small icons
  • Multiple buttons located near each other
  • Repeated cards and controls
  • Duplicative navigation
  • Variable app layouts across production apps.

The dataset is available under an open license, Apache 2.0. Researchers and teams are allowed to download the screenshots and annotations, build their own models, and benchmark against them using the same evaluation metrics.

The benchmark results reveal a wide performance gap

UI-TapBench evaluated six models with zero-shot prompts, and a predictable assessment protocol. From the results, it was clear that the ability to understand the screen differed greatly from the ability to perform precise interactions.

Model Accuracy F1 score p90 latency
Drizz 94.51% 97.18 4.81 seconds
Qwen 3.5-27B 92.98% 96.28 5.92 seconds
Gemini Pro 89.84% 94.65 12.27 seconds
Gemini Flash 81.44% 89.77 8.19 seconds
GPT-5.2 Low 44.83% 61.91 5.00 seconds
GPT-5.1 Low 21.72% 35.68 5.55 seconds

The most important outcome is not just the ranking. It differentiates models that identify the exact tap target from those that understand the instruction conceptually but fail to predict the precise coordinates.

Drizz recorded 94.51% accuracy and GPT-5.1 recorded 21.72%. A model that scores badly might describe the screen correctly and name the correct control, but still tap the control in a region outside its functionality.

This illustrates why general-purpose language or vision benchmarks are inadequate to reflect the performance of mobile automation. Describing a button and tapping it are different things.

Why general-purpose models miss the target

The densely packed interface of mobile applications poses challenges to models. The instruction “Tap the second option” requires not just recognition of elements but an ability to determine their respective boundaries and to map the selected instruction to screen coordinates.

There are several complicating factors.

1. Difficult spatial counting

A list may have six rows with nearly identical design and spacing. The model has to differentiate the second row from the first and the third, and then select the coordinates that are well within the correct bounding box.

Predicting a tap close to the boundary of a row poses a risk. A slight error can place the tap on an adjacent row or on an unfunctional region of the list.

2. Mobile interfaces are unique

General-purpose visual question answering and multimodal models are not calibrated for mobile automation to include a device coordinate space, screen resolution, touch targets, scrolling, and platform design.

This skill is more narrow than general image understanding. Training with more images may not lead to better tap placement.

3. High recall does not guarantee useful automation

A model could have high recall but low precision if it tried to place a tap on almost every screen. 

In mobile testing especially, a wrong tap is more problematic than a missed tap. A missed tap may result in a retry or a clear failure while a wrong tap navigates to a different screen and corrupts all subsequent steps.

4. Accuracy and speed must be evaluated together

In CI/CD, the time to perform an action and the time to wait for the action to be confirmed cannot be neglected. A fast incorrect action may take longer than a slow correct one.

Recovery time from failed interactions must also be taken into consideration.

Why 1.53 percentage points makes a difference

Drizz scored 1.53 percentage points higher than Qwen 3.5-27B. From this perspective, the difference is small.

Assuming a pipeline runs 20 times a day and performs 1000 taps in each run:

  • If the pipeline's accuracy is 94.51 %, there would be about 55 incorrect taps.
  • At 92.98 % accuracy, it would be about 70 incorrect taps.
  • The difference across 20 runs would result in about 300 incorrect taps.

Small changes at the action level can have substantial effects at the scale of a large software development and continuous integration pipeline.

Teams should therefore look at the impact that model accuracy has at the flow level, and not just at the tap level. Some important metrics are:

  • Number of successful flows
  • Number of successful taps
  • Failure recovery rate 
  • False failure rate
  • Mean average time to failure diagnosis
  • Pipeline duration
  • Infrastructure cost

UI-TapBench vs. other existing benchmarks

'End-to-end' benchmarks determine if an agent achieves a goal. Such benchmarks help determine planning, navigation, memory, and recovery.

However, such benchmarks do not guarantee that all individual actions are correct. An agent can tap on the incorrect element, recover through another path, and still achieve the goal. The agent may take erroneous steps but still successfully achieve the final goal.

UI-TapBench concerns itself with the correctness of actions. It is therefore complementary to existing high-level benchmarks.

Evaluating mobile app testing should be a combination of both:

  1. Use UI-TapBench to evaluate spatial grounding and tap accuracy.
  2. Use end-to-end flow benchmarks to evaluate state and navigation.
  3. Use CI/CD to test reliability.
  4. Analyze root cause failures instead of considering downstream assertion failures as defects.

Where do AI-powered mobile tests fit in a modern release pipeline?

AI-powered mobile tests fit best in a layered approach to testing. During pull requests, teams should run a small smoke suite covering important business flows. These tests have to be fast and predictable. If an agent taps inconsistently, the pipeline should capture that as a failure with a screenshot, predicted tap location, tap region, and application state.

Once the pull request is merged, a full regression suite can run across different device models, OS versions, and screen size form factors. This stage is used to identify layout shifts that affect spatial grounding.

Prior to release, teams should run long end-to-end smoke tests involving payment flows, account changes, user onboarding, and other critical business flows. At this stage, the accuracy of taps should be addressed along with the recovery behaviors and failure analysis.

Drizz's platform fits into modern workflows by leveraging AI to reduce the maintenance burden of test automation and reliably interact with interfaces. 

Teams evaluate Drizz based on metrics like tap accuracy, flow completion, test stability, and time-to-failure diagnosis.

A practical checklist for evaluating mobile AI testing tools

Evaluation of mobile AI testing tools should occur with measurable goals. Before adoption of AI testing tools, vendors should be asked for evidence in the following areas:

1. Spatial accuracy

What per-action accuracy is provided for mobile interfaces? What does the vendor mean when they say tap is correct?

2. Real application coverage

Is the vendor's app under evaluation a real mobile app (not demo app) with complex UI, such as menus, lists, controls, etc.?

3. Reproducibility

Are the benchmark dataset, prompts, scoring method and limitations available? The publication of data facilitates validation of results.

4. Sequential reliability

Reliability of tool action should not be evaluated by the success of an individual action. A tool that excels in single-step actions, may still struggle with scrolling actions, input of keystrokes, loading actions, and unpredictable dialogs.

5. CI/CD integration 

Find out how the tool reports failures. The output must contain screenshots, a history of actions, coordinates, details of the device and sufficient information for an engineer to understand the failure.

The next step for mobile testing teams

AI agents need more than screen reading comprehension to work well in mobile CI/CD. They need accurate spatial grounding, prediction of latency, smart recovery mechanisms and clear indication of failures.

UI-TapBench provides a means to measure essential aspects, such as whether an agent taps the desired location, measuring one of the most important aspects. Its 570 screenshots across 20 production apps show a gap that other broader task completion benchmarks attempt to hide.

The dataset is available for independent evaluation, and its limitations are known. Currently, it focuses on Android, English-based single-action interfaces and works best for simple tasks. Future iterations may include iOS, multilingual screens, additional task difficulty and multiple task flows.

For engineering teams, the solution is simple. Test the model on the screens your product uses, measure each action in isolation and in the context of the entire product, and gauge the impact of modeling errors. Mobile testing of AI begins with discussing the taps.

‍

About the Author:

Asad Abrar
LinkedIn logo white letters in a blue rounded square background.
Co-founder & CEO, Drizz
Ex-Coinbase PM and IIT Kharagpur grad killing flaky mobile tests by day, and obsessing over F1 lap timings by night.