Launched this week
Drizz
Mobile tests that write, run, and fix themselves
1.5K followers
Mobile tests that write, run, and fix themselves
1.5K followers
Drizz is an AI-powered mobile test automation platform built around intent-based testing. Simply describe what you want to test in plain English, Drizz executes it on a real device using Vision AI and automatically authors a reusable test case. No scripting, no flaky selectors, no manual maintenance. It adapts to dynamic UIs, integrates with your CI/CD pipeline, and gives your team reliable end-to-end coverage without the overhead.
I prototype in SwiftUI and sometimes my prototypes become the actual production code. Having tests would be great but I don't have time to write Appium scripts. Could I literally test my prototype with Drizz before handing it to the dev team?
Drizz
Hey@ragib_ahsan ,
The beauty of Drizz is that you can write test case in no-code natural language. Yes you can set the prototype and write the steps or even better, describe the test case for us and we will write the steps for you and you can seamlesly run the tests on your local or on your cloud device provider.
You can install Drizz from this link and give it a try.https://www.drizz.dev/download-desktop-app
We just closed our seed round and mobile is our first platform. Haven't set up testing yet. Is it too early to start with Drizz or should we wait until we have more features built?
Drizz
Hi @ragib_ahsan3 ,
Congratulations for closing the Seed round!
You can start testing right away with Drizz. If you encounter any scenario / cases that we are not able to cater, give us a day or two we will prototype and deploy the enhancement!
Looking forward!
Do you expose test results as structured data? I want to pipe results into our data warehouse for trend analysis. Like test pass rates over time, most-failing flows, etc.
Drizz
Hi @md_saquib2 ,
We haven't really built much on test result export functionality yet. But I would be happy to give provide some MCP solution with which you can query your test results anytime in any format for your analysis.
intent-based testing is the right abstraction here. one question: if the UI shifts but the intent doesn't (new onboarding screen, reordered step), does it auto-reconcile or do you redo the test? that's where most vision-ai tools fall apart for us.
Drizz
Hey@haili_yuan
The problem you highlighted is the most common issue faced by QA and devs as of now. One small change in the UI leads to breakage of tests!
With our mission on simplifying and easing the testing journey. We have build a few agents that would be triggered when we identify the test steps are not aligning with the UI, they simply come , identify the missing steps / steps needed to reconnect the test case and voila no more test case falling appart due to new changes on UI.
Would love if you could try out a few scenarios on the tool!
When you write a test intent for iOS, does Drizz reuse that same intent to run on Android too, or do you author separately per platform? Curious whether the vision layer handles the UI differences automatically or if there’s still some per-platform config involved.
Drizz
Hey @sunnyallan ,
Very interesting question. With the intent, we generate the test steps, which are run in automation along with healer agents that would come to fix your test when test breaks due to UI diffs.
Now these test scripts generated are platform agnostic,. They can run on both android and ios , provided the the app flows are similar on both platforms.
the 'tests that fix themselves' claim is the one i'd want evidence for before getting excited. self-healing tests that silently update when the UI changes sounds great until you realize the test is now passing on something different from what you originally intended to test. how does Drizz handle that distinction
Drizz
@ansari_adin Fair pushback. that failure mode is exactly why most 'self-healing' claims age badly.
The way Drizz approaches it: we don't rely on brittle locators at all. Instead we build a deeper understanding of the appL a knowledge graph of flows, states, and intended behavior from previous crawls, and that becomes the baseline for what a test is actually verifying.
So when the UI changes, we're not just asking 'did the test still pass?', we're asking 'did it pass for the reason it was supposed to?' If the intended flow still holds, we adapt. If the underlying behavior diverged from the baseline, it fails loudly and tells you what drifted.
Happy to walk through a concrete example if useful.
This is basically what mobile QA has been missing for years moving from brittle selectors to intent is a big shift.
The real test will be CI reliability over time, but if it holds up, it could seriously reduce maintenance overhead for teams shipping fast.
Drizz
@hassan__shah
Exactly Hassan, that shift from selectors to intent is the core idea behind Drizz.
And yes, long-term CI reliability is the real benchmark. The scripts generated/authored by you can be seamlessly added into CI pipelines and run across widely available cloud integrations.