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.
@zoya_aziz - Yes, it does. You just need download a local launcher of QApilot and you'd be good to create and execute test cases on your local devices.
Reusing existing BDD test cases instead of asking teams to rewrite everything feels like a smart adoption strategy. Has that been the biggest driver of customer interest so far?
@luki_notlowkey - Definitely. The biggest bottlenecks teams have been facing is not writing test cases but actually running them. So, the ability to execute existing test cases using CoWork has been a game-changer for the users.
Report
@charan_tej_kammara The “fails honestly instead of faking a pass” part is the strongest detail for me. In QA, a test that silently adapts in the wrong direction can be more dangerous than a broken test. Human-approved replanning around the original test intent feels like the right balance between speed and trust.
@tkeith - Hi trevor. That's an interesting use case. As of now, we built CoWork for mobile testing only. But it would be interesting to explore more use cases for CoWork and. QApilot in general.
Report
Mobile QA is a strong place for automation because the bottleneck is rarely one test; it is the repeated device, environment, and regression coverage that slows teams down.
The “same QE team, 3x automation” positioning is interesting. I’d be curious how QApilot handles flaky tests and app-state changes, because reliability is usually what determines whether QA teams trust automation or keep falling back to manual checks.
@rahulbhavsar - Test Flakiness and Maintenance are a real pain, especially for mobile testing teams. We built CoWork to replan tests dynamically during execution to bypass flakiness and continue with the tests as long as the intent stays intact.
Report
It’s a great idea. I apologize for my limited understanding. Considering the increasing cost-effectiveness and reliability of code production, why should we rely on agentic testing? I understand that specifications can fail due to changes like button renames, but (at least in our suite), it’s expected that tests will fail, and specifications need to be updated accordingly. Wouldn’t it be more efficient to use deterministic testing combined with a non-deterministic report generator?
@shibin_tv Great question, Shibin. We don’t see agentic testing as a replacement for deterministic tests. Those should stay where behavior is fixed and repeatable.
The challenge is mobile execution. The same flow can behave differently across devices, OS versions, permissions, keyboards, overlays, network states, and timing delays.
Traditional tests often fail on these execution quirks even when the user journey is still valid. CoWork tries to handle that in-run: continue when it is safe, ask when judgment is needed, and fail honestly when the product behavior has truly changed.
Report
The replanning loop is what gets me here — most AI test tools fail silently when the UI changes, and you end up with flaky tests nobody trusts. Human-approved replanning before re-execution is the right call.
Curious how CoWork handles cases where the AI's planned steps diverge significantly from the original test intent — does the human reviewer see a diff of the original vs proposed plan, or just the new steps in isolation?
@renaldo_loko - Thank you, and Great question. The human reviewer does see the diff. The original plan vs the adapted plan. And the decision is with the human whether or not to accept the adapted plan for the future runs.
Report
💡 Bright idea
@charan_tej_kammara That's the right call — a diff view is exactly what you need for trust.
Seeing "here's what was planned, here's what changed, and why" gives reviewers the context to make meaningful decisions rather than rubber-stamping a black box.
Follow-up: do you track accept/reject rates over time per test case? Curious whether certain UI patterns (e.g. dynamic content, animations) generate more replanning requests than others — could be a useful signal for prioritization.
@renaldo_loko - All of the information associated with acceptance/rejection of dynamic replans is saved. It is such a good idea to present this information in a report. Agree that it comes handy. Thank you!
Report
When scale testing mobile applications, how does CoWork handle deep state synchronization or state flakiness across parallel test instances? Is it actively maintaining a synchronized virtual state tree across the instances, or relying on aggressive DOM/view re-verification loops to prevent false negatives?
@juno_dost - Great question. CoWork doesn’t maintain one shared virtual state tree across parallel runs. Each device/run keeps its own execution context and validates against the app model, test intent, and current screen state.
It’s not just repeated view polling either. We use contextual re-verification, checkpoints, and bounded replanning to handle mobile state quirks.
If the journey is still valid, it continues. If the state is polluted or behavior has changed, it surfaces the issue.
Report
💡 Bright idea
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?
@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.
real device testing is the part everyone skips and then regrets. nice to see the human approval step for unexpected states, that's usually where automation quietly lies to you. congrats on the launch.
Replies
looks cool! can it work on my local device?
QApilot's CoWork
AgentKey
QApilot's CoWork
@charan_tej_kammara The “fails honestly instead of faking a pass” part is the strongest detail for me. In QA, a test that silently adapts in the wrong direction can be more dangerous than a broken test. Human-approved replanning around the original test intent feels like the right balance between speed and trust.
QApilot's CoWork
Solid
QApilot's CoWork
Mobile QA is a strong place for automation because the bottleneck is rarely one test; it is the repeated device, environment, and regression coverage that slows teams down.
The “same QE team, 3x automation” positioning is interesting. I’d be curious how QApilot handles flaky tests and app-state changes, because reliability is usually what determines whether QA teams trust automation or keep falling back to manual checks.
QApilot's CoWork
QApilot's CoWork
@shibin_tv Great question, Shibin. We don’t see agentic testing as a replacement for deterministic tests. Those should stay where behavior is fixed and repeatable.
The challenge is mobile execution. The same flow can behave differently across devices, OS versions, permissions, keyboards, overlays, network states, and timing delays.
Traditional tests often fail on these execution quirks even when the user journey is still valid. CoWork tries to handle that in-run: continue when it is safe, ask when judgment is needed, and fail honestly when the product behavior has truly changed.
The replanning loop is what gets me here — most AI test tools fail silently when the UI changes, and you end up with flaky tests nobody trusts. Human-approved replanning before re-execution is the right call.
Curious how CoWork handles cases where the AI's planned steps diverge significantly from the original test intent — does the human reviewer see a diff of the original vs proposed plan, or just the new steps in isolation?
Congrats on the launch 🚀
QApilot's CoWork
@renaldo_loko - Thank you, and Great question. The human reviewer does see the diff. The original plan vs the adapted plan. And the decision is with the human whether or not to accept the adapted plan for the future runs.
@charan_tej_kammara That's the right call — a diff view is exactly what you need for trust.
Seeing "here's what was planned, here's what changed, and why" gives reviewers the context to make meaningful decisions rather than rubber-stamping a black box.
Follow-up: do you track accept/reject rates over time per test case? Curious whether certain UI patterns (e.g. dynamic content, animations) generate more replanning requests than others — could be a useful signal for prioritization.
QApilot's CoWork
@renaldo_loko - All of the information associated with acceptance/rejection of dynamic replans is saved. It is such a good idea to present this information in a report. Agree that it comes handy. Thank you!
When scale testing mobile applications, how does CoWork handle deep state synchronization or state flakiness across parallel test instances? Is it actively maintaining a synchronized virtual state tree across the instances, or relying on aggressive DOM/view re-verification loops to prevent false negatives?
QApilot's CoWork
@juno_dost - Great question. CoWork doesn’t maintain one shared virtual state tree across parallel runs. Each device/run keeps its own execution context and validates against the app model, test intent, and current screen state.
It’s not just repeated view polling either. We use contextual re-verification, checkpoints, and bounded replanning to handle mobile state quirks.
If the journey is still valid, it continues. If the state is polluted or behavior has changed, it surfaces the issue.
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.
FetchSandbox
real device testing is the part everyone skips and then regrets. nice to see the human approval step for unexpected states, that's usually where automation quietly lies to you. congrats on the launch.
QApilot's CoWork
@rnagulapalle - Exactly. Thank you Raj.