the "fails honestly instead of faking a pass" philosophy is what stands out. the maker explained in the launch comments that when the UI changes, CoWork replans against the current app state but anchors to the original intent of the step rather than the old UI path - if a new path could change what the test is actually validating, it stops and asks for approval instead of silently continuing. that distinction between adapting to harmless UI change versus letting a test drift into validating the wrong thing is exactly the failure mode that makes most mobile automation untrustworthy after a few releases.
someone asked in the comments what percentage of failures actually need manual intervention versus recovering on their own in production, since that's what determines the real maintenance cost over time. the maker's honest answer was that they're tracking it internally but don't want to quote a broad number yet because it varies by app and flow. that's a fair answer for a 2-month-old product, but it's also exactly the number a team evaluating this for a sprint workflow needs before committing, so publishing even a rough range would help a lot.
TestMu AI markets itself as a full-stack agentic QE platform, which sounded like it covers more ground on paper. but QApilot's CoWork is scoped specifically to the mobile execution problem - turning test cases you already wrote into something that runs on a real device and knows when to stop and ask instead of guessing. for a QA team that already has test cases but low execution coverage, a narrower tool that's honest about its limits felt like a safer bet than a broader agentic platform still proving itself.

My fav part was that it converts existing natural-language or BDD test cases into executable mobile tests. Also it adapts to harmless UI changes, pop-ups, timing issues, and altered flows. I like that it preserves test intent and asks for human approval when adaptation could change meaning.
Thankfully it “fails honestly” instead of producing misleading passes when it cannot proceed. Strong mobile-first focus, including real-device execution and support for Android, iOS, and Flutter.
I wish that I could publish real-world auto-recovery versus manual-intervention rates. Explaination on replanning decisions more clearly during and after each test would also be helpful
QApilot handles mobile UI changes without completely breaking the pipeline. Most tools claim to be "autonomous," but the moment a button label changes or an unexpected popup appears, the whole build fails. QApilot's CoWork feature feels much more pragmatic it actually attempts to replan contextually, and if it hits a point of true ambiguity (like an OTP requirement or a major flow pivot), it brings a human into the loop instead of faking a pass. Being able to feed plain test cases into it and get execution on real devices without sinking weeks into script maintenance is a huge win for mobile release cycles.
The execution intelligence is solid, but I’d love more granular control and visibility into why the AI made specific replanning decisions during a run.
We looked few cloud testing setups like BrowserStack combined with Appium, as well as other modern AI QA tools like Autify and TestRigor. While traditional Appium setups offer control, the ongoing maintenance drag for mobile releases is exhausting. QApilot stood out because it’s purpose-built for mobile frameworks (including Flutter and React Native) right out of the gate, rather than trying to be a generic web-testing tool with mobile tacked on.
We had a manual QA team running most of our regression through Excel-based test cases the problem was test steps in one place, execution in someone's head. CoWork mode was the thing that actually helped: it let us feed in our existing test cases instead of starting automation from scratch, so we weren't throwing away months of manual QA knowledge to get to automation. That "automate what you already have" angle is rare most tools assume you're starting fresh.
Honestly, most of my hands-on time has been in CoWork, so I can't speak in detail to the Crawler, Record & Play, or dual device testing modes yet they're on the platform and worth checking out, but I'd rather not review what I haven't used. One thing I'd genuinely like improved: better visibility/documentation for teams like ours who are only using one mode, so it's clearer what the other modes would add before we invest time exploring them.
We looked at Appium (too much setup and maintenance overhead for a small team) and BrowserStack's own automation tooling (good device coverage, but not built around converting existing manual test cases). QApilot's CoWork approach to migrating from Excel-based cases was the deciding factor over both.
I liked most about QApilot is how quickly I could get into testing without spending a lot of time preparing everything first. I could give it the app and start checking real user flows pretty quickly. It was especially useful for catching issues across different screens and making sure the main journeys were working as expected.
I’d like more options to fine-tune the tests before they run, especially around choosing specific screens or flows to focus on. More detailed failure reports would also make it easier to understand and reproduce issues.
I looked at traditional mobile automation approaches where I’d have to prepare test cases and scripts before getting started. That setup can take quite a bit of time, especially when I just want to check the main flows. QApilot felt more straightforward for that kind of testing.
It tackles one of the annoying parts of mobile QA, turning test cases into something that runs reliably on devices.
With CoWork, I can upload the existing test cases then it plans the steps and executes them on a real device and the part that really caught my attention is how it handles changes during execution. If the app has a different label, an unexpected popup, or the flow changes, it doesn't just blindly continue. It can replan and bring a human into the loop when a decision actually matters. That feels much more practical than treating AI as something that should always make the final call.
I also like that it's focused heavily on mobile testing, including Android, iOS and Flutter, rather than trying to be an AI tool for every type of testing at once.
I'd love to see even more visibility into what QApilot is doing while a test is running especially why it decided to replan a step, what changed in the app, and why it eventually needed human approval.
I'd also like more control over execution settings and environments as the platform matures. That's probably less important when you're getting started, but it becomes increasingly important when a team is running a large regression suite across different devices and builds.
I’d normally look at traditional mobile automation frameworks and the larger cloud testing platforms for this kind of workflow.
The problem is that getting from an existing test case to dependable automated execution can still involve a fair amount of scripting, maintenance and debugging. QApilot feels different because the starting point can simply be the test case you already have.
For teams that already have a decent collection of manual or BDD test cases but don't have the time to automate all of them, that seems like a pretty useful middle ground.
CoWork makes the idea of AI-powered testing feel much more practical. Instead of spending time writing automation scripts for every test, you can give it your existing test cases and let it handle the execution.
I particularly like the way it can adapt to changes during testing and bring a human in when it needs confirmation. Being able to test on real mobile devices is another big plus.
More CI/CD and test management integrations would make it even more useful for teams with established QA workflows. I’d also like to see more detailed execution insights.
Overall, definitely worth checking out if you’re looking to reduce the manual effort involved in mobile testing.
I’ve looked at traditional mobile automation tools and a few AI-based testing platforms. CoWork feels simpler because you can start with the test cases you already have.
I tried both Crawler and Dual Device Testing, and both were surprisingly useful for different reasons. Crawler was probably my favorite for getting started quickly. I just uploaded the APK/IPA and it started exploring the app and running happy-path tests without me having to write a single test step. The knowledge graph it creates along the way was also really useful for understanding the app structure. Dual Device Testing was convenient for testing workflows where two apps need to interact. I could test the customer and partner apps together in real time, including the texting and approval flow, instead of testing each app separately and trying to connect the dots later.
I’d love to see more control over which flows the Crawler prioritizes and more detailed options for customizing dual-device scenarios. Overall, a really convenient way to get initial mobile test coverage without a lot of setup.
I tried to write scripts using Appium and few automation tools, but most of them require test cases or scripts upfront. The ability to start directly with the app itself was what made Crawler stand out for me.


