Introduction

How Drizz works — Vision AI, plain-English commands, and the five stages every test step runs through.

Drizz automates mobile apps from plain-English instructions, resolving each target visually at run time.

Platforms	Android · iOS · Mobile web
What you write	Plain English, one instruction per line
What you don't need	No selectors, no XPath, no accessibility IDs etc
Portability	The same file runs on Android and iOS
Watch out	Ambiguous descriptions resolve to different elements between runs — use the app's exact visible wording for better control and stable tests

A test looks like this

# ShopEase — search for a product

OPEN_APP com.shopease.android
Wait Until 5 Seconds

Validate that the home screen is visible

Tap on the search icon
Type running shoes in the search field
Tap on the first search result
Wait Until 3 Seconds

Validate that the product detail page is visible

No setup file, no page objects, no element locators.

What Drizz does not require

No selectors	A step names the element as it appears: Tap on Login CTA, not driver.findElement(By.id("btn_login_primary")). Renaming an ID does not break a test
One script, both platforms	A step describes intent; Drizz resolves it against the current screen. Some commands differ per platform — see Known limitations
No instrumentation	No SDK, no debug build, no test code in the app. Drizz drives the app from outside

How a step executes

Every line runs through the same five stages.

Stage	What happens
1 · Capture	The system captures the current screen and uses available visual context to better understand what’s displayed.
2 · Classify	The line is routed to a command type — tap, type, validate, scroll, system. The first word of the line determines the routing
3 · Locate	Vision AI finds the target described and returns its position. This stage fails when a description is ambiguous
4 · Act	The tap, type or swipe happens at that position
5 · Verify	Drizz confirms the screen changed as the step implies. A Validate gets up to 3 attempts before failing

Note: The 3 attempts do not replace a wait. Add Wait Until <n> Seconds before a step that runs after navigation — see Waits & timing.

Automatic behavior

Caching	Drizz reuses how it resolved a step on a screen it has seen before. Cached steps run faster and cost fewer DT, so a suite speeds up over its first few runs. See Caching
Unblocking	A popup in the way — a permission prompt, a promo sheet, a network retry — is dismissed using the app's blocker rules, with no step in the script. See Memory & blockers

Common mistakes

What you write	What happens
Tap on the button	Resolves to a different element depending on screen state. Quote the element's visible label
Tap on Proceed to Pay when the button reads Charge Now	Paraphrasing misses the element, or hits the wrong one. For strict logic use double quotes, else the test runs purely on the intent to pass the screen state
Scroll with no direction	Unreliable. Always give a direction and quote the target

Next

• Quickstart: your first test

• Platform & device support

• Use cases

---

Last updated: 6 August 2026