•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
Automation was supposed to make mobile testing effortless.
Instead, it gave your team a second product to maintain.
AI can write code now. Thanks to Cursor, Codex, Claude Code.
Yet every new release breaks something.
UI updates change selectors.
Redesigns cause dozens of tests to take down at once.
With every failure, trust in the product and your testing suite takes a nosedive. The test suite your team built for confidence becomes the one thing nobody wants to open.
It's not a fault of your QA engineers or your developers. It's not a coverage gap issue either.
If your mobile testing automation is built on top of brittle selectors, fragile scripts, and implementations built for software to ship every 3 to 6 months instead of every day, it has already become the bottleneck.
While your engineering teams learnt to use AI to write code, review pull requests and speed up releases, why is your mobile testing automation still behaves the way it did in 2016.
The new approach?
A mobile testing automation that is not built on selectors. One that survives UI changes instead of collapsing after every design change. One that reads your application like a human tester, and gives engineering teams the hours they spend repairing tests.
In this article, we cover the reasons traditional mobile test automation is no longer the enterprise level standard, and how to ensure that testing doesn't remain your bottleneck anymore.
Ready to learn more about the future of mobile testing automation, let's dive in.
It is rare to hear about new test coverage when interviewing QA leads about sprints. Teams that use selector-based frameworks spend 30 to 50 percent of their sprints on writing new tests. Even the 5-person QA team, which costs about $60 per hour, generates about $234,000 annually on test repairs without adding a single new scenario.
The second cost is less obvious. Once a test suite fails often enough, due to reasons other than defects, people stop looking at the results. Red builds are passed. Specs that fail are skipped with a comment to fix them later. And your test suite is still taking money and time while it is not doing its job.
Testing is supposed to make your app resilient to changes. But in your testing suite, a selector points to an implementation detail - a resource ID, an XPath, an accessibility label, a node index - none of which has any idea what a Continue button looks like and what it's for. It just knows where one specific element sits inside the view hierarchy. Change the hierarchy and the test fails, even when a human reviewer would notice nothing at all.
There are 4 forces that keep changing your hierarchy, and none of them sits under your QA's control:
A tweak in the product copy from Sign in to Log In, two screens reordered in a flow, or when a component is wrapped in a new container, the test fails. A normal day at product work and breaks locators, breaking your testing suit with it.
With the pace of innovation, every little upgrade brings in changes that affect your testing suite. SDK upgrades, UI library version changes, and refactors that alter generated IDs and view structure. Selector rot is a real bottleneck.
Even the OS your application depends on such as Android and iOS continue to ship changes to system UI, permission dialogs, and rendering behaviour on their own schedule. And when they do, your test fails again.
The problem compounds with device fragmentation. The same build renders differently across 24,000 Android device models.. A locator that works on a Pixel fails on a mid-range handset with a different screen density.
If you put all this together, you'll come to the conclusion that test maintenance is not a discipline problem. Hiring more test automation engineers doesn't change the outcome at all, it only scales your cost.
Using page object model, you keep every locator in one file which means a UI change needs only one edit instead of forty. But POM doesn't eliminate maintenance for you. If your entire login page is redesigned, you'll still need to change the page-object code. While POM does make UI changes cheaper to maintain, it doesn't prevent UI changes from accumulating as the application grows in size.
Timing only treats symptoms.
A UI test can fail because it tries to interact with something before the page is ready. A retry loop can make a flaky test become reliable. However, it also makes your test suite dramatically slower if every failed test is getting a retry or a wait.
Retry/wait solves the problem where the element exists, but it isn't ready yet. However, it fails when the element itself doesn't exist anymore.
A self-healing locator system tries to find alternatives when the original locator fails. They are useful for small UI changes. However, when the whole page goes through a redesign, they might not find an equivalent locator because every candidate locator refers to a layout that is no longer there.
A human tester will never look at a view hierarchy. They look at a screen, find a button that says Continue, and click it. You can redesign the screen, or move the button, and they will still find it in under a second.
Drizz’s Vision AI similarly applies this approach to automation. Drizz executes tests based on what comes into view on real iOS and Android devices, no selectors are used in the tests, and we run tests on the configured screen. You provide steps in plain English, and describe the flow like you would to a new employee, and a single test runs on both platforms rather than having to create two separate scripted suites.
The tangible difference is seen in 3 areas:
With Drizz, you don’t need to code tests. You simply need to write tests in plain English. Also, you don’t need to be a QA or automation engineer to author these tests. Drizz can capture roughly 200 tests each month for a manual QA, compared to about 15 with Appium, because test writing no longer requires element inspection or fluency with the framework.
Drizz reads the screen as a human would without relying on selectors or code. This is the reason behind the drop in flakiness from about 15% to around 5%. Instead of sleeping for a specified duration, each step checks to see what screen displays.
There are no selectors in the suite and because of this, a whole range of breakage is no longer an issue. Teams see almost a 70% drop in maintenance within 2 to 3 months, returning most of a sprint to the coverage that had been previously neglected, such as payment, deep links, and permission edge cases.
Since these numbers are from Drizz's reporting, treat them as a hypothesis to test against your app, rather than a certainty.
This change is not about integrating AI into your pipeline or taking coding activities out of your workflow. It’s about eliminating the dependency that is causing the breakdowns.
Tests that describe your app through the lens of implementation details will break every time those details change, and someone on your team will have to pay for it in sprint hours.
Tests that are written against the user interface will survive the redesign because the button is still on the screen. This is exactly what Drizz helps you achieve.
©Drizz 2026 • All Rights Reserved
