Launched this week
QApilot's CoWork
3x Mobile Automation. Same QE Team.
636 followers
3x Mobile Automation. Same QE Team.
636 followers
CoWork turns existing test cases into executable mobile automation with AI planning, human-approved replanning, and real-device execution on iOS, Android, and Flutter.
Interactive
Payment Required
Launch Team / Built With
The thing that kills most AI test-gen tools in practice is maintenance: the agent writes a suite, the UI changes next sprint, and now you're drowning in false failures. Does CoWork self-heal selectors when the DOM shifts, and can it tell a real regression from a benign markup change? That signal-to-noise ratio is what decides whether teams keep the suite or quietly delete it.
QApilot's CoWork
@mikebrandswarm - Yes, maintenance is the biggest pain for QA teams. The execution engine that executes the tests written by CoWork does AI-Self healing if the DOM shifts. We have equipped it with a bunch of fallbacks that enables it to identify where to click on when DOM shifts. The fallbacks range from text, image, parent-child hierarchies, etc., essentially solving the fragile broken tests.
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 part feels like the important bit. I’ve seen mobile test agents get scary when they quietly guess through OTPs or changed labels. Curious if teams can set different approval rules for smoke tests vs release-blocking flows?
QApilot's CoWork
@xiaosong001 - thank you! That's a great way to think about this. Currently, the approval rules are same and the decision is left for the human in the loop to decide how to act on the approval for different flow. But this is a valuable suggestion for our team to add to our roadmap.
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.
The selector breakage problem is real.... we've seen entire automation suites go down after a single navigation update.
Curious how CoWork handles dynamic test data mid-execution. if a flow requires an OTP or an auth password during the run, can that be injected in real time or does everything need to be pre-configured before the session starts?
QApilot's CoWork
@harini_mukesh There are a couple of we handle test data on CoWork, depending on the type of the test data. The user can choose to plug in the test data as part of the natural language test context that is given to CoWork. CoWork will make use of it as needed.
Otherwise, if CoWork comes across an input field like an OTP during its journey, it prompts the user to enter the input, and once the user does that, it continues to autonomously execute the rest of the steps. So, yes. Depending upon the test data and user preference, it can be injected in real-time or pre-configured.
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?
QApilot's CoWork
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.