•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
•
Drizz raises $2.7M in seed funding •
•
Featured on Forbes
Decide what to test.
Drizz reads your app, maps everything that could happen around each feature, and proposes what to test, with the reasoning attached. Your team approves the plan. Drizz writes the tests.
The gap
An experienced QA engineer runs this expansion for every feature, every release. Mostly in their head.
What it costs
Customers charged. Orders never created. Nothing failed in CI, because nothing was checking.
How it works
The same coupon feature, followed through all three steps.
Drizz walks the application on a device and records what is actually there: every screen, control and route, and every way into a journey. That’s why a later “Tap Apply” points at a button that exists.
Drizz turns the map into a prioritised plan and explains each entry with what it observed. Your QA lead reviews it the way they’d review a colleague’s: add what Drizz couldn’t know, drop what doesn’t apply.
Approved scenarios become runnable tests, in plain English or as code alongside your existing suite. Every test states what counts as a pass. A test that only clicks through a flow is rejected.
Four steps, nothing checked. This passes on every run even when the coupon is applied at the wrong rate, so it would never tell you the discount broke.
The difference
Because they’re written from a description of the app. Here’s what changes when they’re written from the app itself.
“Seven tests failed. None were bugs. Each had trusted a route read from source code.”
That was one of our own runs. We didn’t ask the system to be more careful. We made it impossible to approve a route no device had walked. The principle: never check work against the same source that produced it.
Control
Two human gates, placed where judgement matters: is this the right set of things to test, and are these the right tests.
Evaluation
Ask what the tool saw before it wrote the step. If the answer is a spec or the source, its navigation is inferred.
A list without reasons can’t be reviewed, only accepted.
Ask which decisions a person makes, and what happens if they change one.
A step that depends on a route no device has reached is a guess with good grammar.
If it never rejects its own output, it has no standard. A walkthrough that asserts nothing shouldn’t pass.
Measure it in a real session. Reading generated steps line by line isn’t a review.
Ask whether the scope is rebuilt from scratch or updated against what actually changed.
Scope
In development
The scope decision is separate from everything downstream, so each new input connects to it without rebuilding the rest. These are not available today.
Acceptance criteria, documented edge cases and designed states such as empty, error and offline, feeding scope before the build lands.
For a pull request: the shared components it touched, and the journeys that quietly depend on them.
The subset of your existing suite relevant to a change, with the reason each test was included.
Areas that have failed before carry more weight in the scope when related code changes.
Resources
Benchmarks, calculators and checklists you can use whether or not you pick Drizz.
94.51% tap accuracy against frontier models. 570 screenshots, 20 apps, open dataset.
Download the report →What your current suite costs and what Vision AI saves. Four inputs, no signup.
Run the numbers →Pre-release checks across functional, UI, performance, security, device and network.
Get the checklist →11 tools compared on real-device coverage, CI fit and maintenance burden.
Compare tools →FAQs
Test planning is deciding what to test before tests are written: which scenarios matter for a feature, why each is in scope, and which can be left out. It sits between a requirement and a test suite, and it determines coverage more than execution does.
Start from what should happen, then expand into what could: wrong input, repeated actions, network failure, calculation edges, and different account states. A single requirement line commonly expands into twenty or more scenarios.
Because a passing suite only proves the tests that were written. If a scenario was never scoped, nothing checks it, and CI stays green while the defect reaches production.
AI can propose a scope and explain its reasoning. It cannot weigh business risk, which is why Drizz puts the plan in front of your QA lead to approve, edit or reject before any test is written.
Tests generated from a document assume the app matches the document. Drizz walks the app on a real device first, so every step refers to a control it has seen on a screen it can reach.
A test that only taps through a flow without asserting anything is rejected. Every approved test states what counts as a pass.
Your team, at two points: once on the proposed scope, and again on the written test cases. Nothing enters the suite automatically.
No. Exploratory testing finds the problems nobody thought to look for. Test planning covers the scenarios that can be anticipated, so exploratory time isn’t spent on them.
In a first session, point Drizz at your app and review the journey map and proposed scope it produces.
Upload an .ipa, describe a flow, watch it run on a real iPhone. Twenty minutes, no framework setup.
©Drizz 2026 • All Rights Reserved
