QApilot's CoWork - 3x Mobile Automation. Same QE Team.
by•
CoWork turns existing test cases into executable mobile automation with AI planning, human-approved replanning, and real-device execution on iOS, Android, and Flutter.
Replies
Best
the six-months-to-automate part is real. my team gave up automating our iOS app last year because every release broke the selectors. went back to manual regression and shipped slower for 6 months.
what i'd want to know about qapilot: when an iOS update changes the entire navigation hierarchy, does the AI re-plan or does it break the same way our selectors did? that's the test for whether this actually saves a QA team or just shifts the breakage to a different layer.
@thenameisarian That's a real pain, especially for fast moving mobile app teams. We built CoWork's planning module such that it intelligently replans, finds new correct selectors, and executes the tests. The QA can choose to update these selectors as default for the future automation runs too. Essentially saving QA's time and effort to focus on test intent rather than maintenance.
@barath_kanna_bk Hello Bharat. Thank you! On a fundamental level, all the automation is an Appium Script. However, Appium notoriously falls short for quite a few use cases, especially on Flutter. We also built a middleware on top of Appium to handle the limitations. So, in essence, it's a combination of Appium and QApilot middleware.
@mark_ph_m Hello Mark. Thank you. We've built QApilot's CoWork specifically for mobile application testing. It is capable of testing web views within mobile apps. That is the extent of our focus.
Love the framing that the real bottleneck isn't writing test cases and agreed it's the execution layer.
Curious: when CoWork replans after encountering an unexpected UI change, how do you prevent it from "hallucinating" a valid path and accidentally masking a genuine regression instead of surfacing it?
@harkirat_singh3777 Precisely! The real bottleneck is the execution layer.
Talking about hallucinations, we ground our plan/replan decisions using a knowledge graph. It is built using an app crawler that we built in-house.
Report
How would this compare to doing UI automation testing with a tool like Selenium or CypressJS
@schott_taylor - Thanks for asking. The biggest pain with scripting frameworks like selenium or Appium is the maintenance effort, especially considering the rapidly changing nature of the mobile applications. We have built CoWork to precisely handle that problem. So that teams can focus on test intent over maintenance.
Report
Congrats on the launch! 🚀
I like the human-approved replanning approach. Mobile automation often breaks on small UI changes, popups, so having AI adapt while still asking for approval feels like the right balance.
Curious how CoWork handles flaky test behavior across different real devices and OS versions.
@prashant_patil14 - Thank you! Yes, one of the biggest problems with mobile app testing is device fragmentation and the flakiness that comes with it. We have a layer of self-healing on our product that handles the quirks of different screen sizes and OEMs.
Basically, with CoWork, you create a set of automatable test cases on any single device and be able to execute on any other device without coming across flakiness. We do a combination of image processing and parent-child hierarchies.
Report
The replanning-on-UI-change part is the real claim here - most mobile suites die exactly when a label moves or an unexpected popup shows up, so an agent that recovers is genuinely useful. When CoWork replans around a changed label, does it persist the adapted step back into the BDD/Gherkin definition so the next run is deterministic, or does it re-infer the path every run (which would make pass/fail non-reproducible across CI runs)? And does execution happen on a hosted device farm or on my own connected devices - that matters for builds behind auth or internal-only distribution.
@hi_i_am_mimo Wonderful question. We gave that control to the human in the loop - to decide whether to save the adapted steps as the default for all the future runs or to roll back the adapted steps. Once CoWork replans and completes a run, the user can choose to accept the test steps and ingest them into the test suite or reject them and re-run CoWork as needed.
We believe that the judgement better lie in the hands of the human.
Report
That human-in-the-loop accept/reject is the right default - auto-persisting silently is exactly how suites quietly drift out of sync. One follow-up on the accept path: when I ingest an adapted step, does it get written back as readable Gherkin/BDD text I can diff in a PR, or as an opaque recorded-selector blob? The first stays reviewable by the team; the second tends to rot.
This feels especially useful for teams that already have test cases written down, but still end up doing too much manual release checking because automation takes too long to maintain.
The human-approved replanning part is the most important detail to me. For QA, I’d rather have the system pause and ask when something changes than confidently fake its way through a broken flow :)
Curious how CoWork handles UI changes over time. does it learn from approved replans so the same changed label or popup does not need approval every time?
@andrasczeizel - "I’d rather have the system pause and ask when something changes" - exactly what our approach to building an autonomous system with human in the centre. And as per the approved replans once the test execution is done, we gave the control again to the human in the loop whether to ingest the approved replans to the test suite and use them for further runs. That way the wouldn't need approval every time.
Report
Charan, the honest-fail and intent-anchoring already won me over (saw your answer to David), so let me push on the part that decides whether this scales: the human approval itself.
A single replan-with-approval is clearly the right call. But a regression suite is hundreds of tests, and a UI change rarely hits just one, a renamed "Checkout" button can ripple across 40 flows. So my real question: when a human approves a replan once, does that decision propagate, does CoWork remember it for the rest of the run and the next one, or does the same change get re-surfaced 40 times? If every approval is a one-off, the human control that makes it trustworthy quietly becomes the bottleneck that kills the 3x. The magic version is one approval teaching the whole suite.
Put simply: does an approved replan become a durable update to the test, or just a per-run decision? That's the line between "AI with a human checkpoint" and "a human clicking approve 200 times."
Congrats on the launch, genuinely strong positioning :)
@keirodev - That's a really great insight, Kevin. We implemented a per-run approval but I totally see how it gets frustrating real quick to approve the same thing 200 times. Noted. Our team have their thinking hats on to implement this.
Report
The human-approved replanning is the right call for mobile. One question: when a test needs to switch between apps mid-flow (e.g., grab an OTP from email, then switch back), does CoWork handle that as one session, or does cross-app context reset?
@christian_knautCurrently, we work with static OTPs for testing. However, we understand that switching between apps for certain test cases is a real need and we are seeing more and more requirements for the same. Something to think about for my team. Thank you for bringing that up.
Replies
the six-months-to-automate part is real. my team gave up automating our iOS app last year because every release broke the selectors. went back to manual regression and shipped slower for 6 months.
what i'd want to know about qapilot: when an iOS update changes the entire navigation hierarchy, does the AI re-plan or does it break the same way our selectors did? that's the test for whether this actually saves a QA team or just shifts the breakage to a different layer.
QApilot's CoWork
@thenameisarian That's a real pain, especially for fast moving mobile app teams. We built CoWork's planning module such that it intelligently replans, finds new correct selectors, and executes the tests. The QA can choose to update these selectors as default for the future automation runs too. Essentially saving QA's time and effort to focus on test intent rather than maintenance.
Oxlo.ai
Congrats on the launch guys!!
Nice idea! Is the generated automation framework-agnostic, or does it target a specific testing framework?
QApilot's CoWork
@barath_kanna_bk Hello Bharat. Thank you! On a fundamental level, all the automation is an Appium Script. However, Appium notoriously falls short for quite a few use cases, especially on Flutter. We also built a middleware on top of Appium to handle the limitations. So, in essence, it's a combination of Appium and QApilot middleware.
Oxlo.ai
@charan_tej_kammara Makes sense.
Appium alone has its limitations, so building a middleware layer is a smart approach.
QApilot's CoWork
@barath_kanna_bk Precisely. Thanks for sharing your thoughts.
Wow. Nice one. Do it have the same operational function for web? How variety of the test cases this cover?
QApilot's CoWork
@mark_ph_m Hello Mark. Thank you. We've built QApilot's CoWork specifically for mobile application testing. It is capable of testing web views within mobile apps. That is the extent of our focus.
Zivy
Congratulations on the launch, @charan_tej_kammara @jsurendranathreddy @vidushee_geetam !
Love the framing that the real bottleneck isn't writing test cases and agreed it's the execution layer.
Curious: when CoWork replans after encountering an unexpected UI change, how do you prevent it from "hallucinating" a valid path and accidentally masking a genuine regression instead of surfacing it?
Observer
How would this compare to doing UI automation testing with a tool like Selenium or CypressJS
QApilot's CoWork
Congrats on the launch! 🚀
I like the human-approved replanning approach. Mobile automation often breaks on small UI changes, popups, so having AI adapt while still asking for approval feels like the right balance.
Curious how CoWork handles flaky test behavior across different real devices and OS versions.
QApilot's CoWork
The replanning-on-UI-change part is the real claim here - most mobile suites die exactly when a label moves or an unexpected popup shows up, so an agent that recovers is genuinely useful. When CoWork replans around a changed label, does it persist the adapted step back into the BDD/Gherkin definition so the next run is deterministic, or does it re-infer the path every run (which would make pass/fail non-reproducible across CI runs)? And does execution happen on a hosted device farm or on my own connected devices - that matters for builds behind auth or internal-only distribution.
QApilot's CoWork
@hi_i_am_mimo Wonderful question. We gave that control to the human in the loop - to decide whether to save the adapted steps as the default for all the future runs or to roll back the adapted steps. Once CoWork replans and completes a run, the user can choose to accept the test steps and ingest them into the test suite or reject them and re-run CoWork as needed.
We believe that the judgement better lie in the hands of the human.
That human-in-the-loop accept/reject is the right default - auto-persisting silently is exactly how suites quietly drift out of sync. One follow-up on the accept path: when I ingest an adapted step, does it get written back as readable Gherkin/BDD text I can diff in a PR, or as an opaque recorded-selector blob? The first stays reviewable by the team; the second tends to rot.
YourSitee
This feels especially useful for teams that already have test cases written down, but still end up doing too much manual release checking because automation takes too long to maintain.
The human-approved replanning part is the most important detail to me. For QA, I’d rather have the system pause and ask when something changes than confidently fake its way through a broken flow :)
Curious how CoWork handles UI changes over time. does it learn from approved replans so the same changed label or popup does not need approval every time?
QApilot's CoWork
@andrasczeizel - "I’d rather have the system pause and ask when something changes" - exactly what our approach to building an autonomous system with human in the centre. And as per the approved replans once the test execution is done, we gave the control again to the human in the loop whether to ingest the approved replans to the test suite and use them for further runs. That way the wouldn't need approval every time.
Charan, the honest-fail and intent-anchoring already won me over (saw your answer to David), so let me push on the part that decides whether this scales: the human approval itself.
A single replan-with-approval is clearly the right call. But a regression suite is hundreds of tests, and a UI change rarely hits just one, a renamed "Checkout" button can ripple across 40 flows. So my real question: when a human approves a replan once, does that decision propagate, does CoWork remember it for the rest of the run and the next one, or does the same change get re-surfaced 40 times? If every approval is a one-off, the human control that makes it trustworthy quietly becomes the bottleneck that kills the 3x. The magic version is one approval teaching the whole suite.
Put simply: does an approved replan become a durable update to the test, or just a per-run decision? That's the line between "AI with a human checkpoint" and "a human clicking approve 200 times."
Congrats on the launch, genuinely strong positioning :)
QApilot's CoWork
@keirodev - That's a really great insight, Kevin. We implemented a per-run approval but I totally see how it gets frustrating real quick to approve the same thing 200 times. Noted. Our team have their thinking hats on to implement this.
The human-approved replanning is the right call for mobile. One question: when a test needs to switch between apps mid-flow (e.g., grab an OTP from email, then switch back), does CoWork handle that as one session, or does cross-app context reset?
QApilot's CoWork
@christian_knautCurrently, we work with static OTPs for testing. However, we understand that switching between apps for certain test cases is a real need and we are seeing more and more requirements for the same. Something to think about for my team. Thank you for bringing that up.