Launching today
QApilot
3x Mobile Automation. Same QE Team.
353 followers
3x Mobile Automation. Same QE Team.
353 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
QApilot
Hey everyone, Charan from QApilot here.
Every QA team knows what they want to test. "Log in, add an item to the cart, check the order confirmation." Saying it takes ten seconds. Then the team spends six months turning that sentence into something a machine will run: step definitions, selectors, automation glue, flaky scripts that break on every UI change.
The intent was never the hard part. The execution layer was the tax.
CoWork takes your existing natural-language or BDD test cases, converts them into structured BDD/Gherkin context, builds an execution plan, and runs the test on a real mobile device.
When the app behaves differently, like a changed label, unexpected popup, or interrupted flow, CoWork replans and asks for human approval before moving ahead. When it needs input, like an OTP, it pauses instead of guessing. If it can’t proceed, it fails honestly instead of faking a pass.
Who it’s for: QA leaders, SDETs, mobile engineering teams, and product teams with existing test cases but low execution coverage before releases.
Common use cases: Regression testing, Release readiness, checkout/login flows, OTP-heavy journeys, app flows that break often, and teams trying to reduce manual execution without rewriting everything from scratch.
What makes CoWork different is the balance: AI execution where it can move fast, human control where judgment matters.
If you run mobile tests, I’d genuinely love your take. Try it here: https://qapilot.io/product/cowork
Thanks for being here for the launch. I’ll be in the thread all day reading every comment.
-- Charan Tej, Product Guy @QApilot's CoWork
@charan_tej_kammara The "fails honestly instead of faking a pass" line is underrated. Most automation lies to you when the UI shifts under it, and a test that drifts and silently passes is worse than no test. When CoWork hits a screen that no longer matches the plan, does the human-approved replanning re-anchor to the intent of the step or to the old UI path? That distinction is what separates flaky from durable.
QApilot
@charan_tej_kammara The biggest challenge with mobile automation has never been writing the first version. It’s what happens after the app changes for the tenth or twentieth release.
You mention CoWork can replan execution when screens, labels or flows change, while still asking for human approval before changing intent. How much of that actually happens automatically in production? For teams using this every sprint, what percentage of failures end up needing manual intervention versus successfully recovering on their own?
That number would tell me more than any feature list because maintenance is usually where automation becomes expensive.
QApilot
@vidushee_geetam The idea makes sense technically, but I’m interested in the operational impact.
If a team already has a mature manual regression process, what changes after six months of using CoWork? Is the biggest improvement shorter release cycles, higher regression coverage, fewer flaky tests, or simply less engineering time spent maintaining automation?
I’d be interested to know which metric your existing customers see improve first because that’s ultimately what teams will justify the investment with.
Observer
The "human-approved replanning" step is the detail that makes this production-viable. Most AI automation tools pitch full autonomy, but that is exactly where QA teams lose confidence in the output. Having the AI propose the plan change and a human sign off before execution means you get the speed gains without the "the bot went rogue on staging" stories.
How does the replanning loop work when a test fails mid-run? Does it pause for approval every time, or only when the deviation is above some threshold?
QApilot
@mohammed_abd_ilah_neggache - Precisely. You've captured the core of CoWork'v value. The replanning happens automatically as long as the original test intent holds true. Any interruption handling, Label changes, etc., will be handled by CoWork autonomously through replanning.
However, if the CoWork had to replan such that the test intent changes, it goes for human approval. So, the original test intent acts as the threshold of deviation here.
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
@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
@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.
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
@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.