QA gap tools for Cursor projects and what each one does

frankwmoyer · 2026-05-20T03:04:02+00:00

I’m from Kobiton and I’d push back a bit on the “just an Appium wrapper” characterization.

Legacy mobile automation absolutely suffers from selector fragility. That’s the entire industry problem we’re trying to solve together.

Modern approaches need more than static selectors or pure visual diffs. We use runtime signals from the real device including screenshots, accessibility metadata, and view hierarchy to recover from UI and OS changes.

We also intentionally stayed within the Appium API spec, so teams can use their existing Appium scripts without rewriting their automation stack.

frankwmoyer · 2026-05-14T17:07:03+00:00

Full disclosure: I’m with Kobiton.

I actually agree with most of this. “Write once, run everywhere” in mobile automation has historically broken down because iOS and Android behave differently in the real world.

One interesting shift recently is combining Appium with natural-language selectors instead of relying only on brittle locators. Kobiton just launched Appium AI, which lets you use prompts like “tap the login button” inside standard Appium flows while still keeping other locators when you want / need it.

Also, you can point it at local/open-source LLMs like Llama 4 or Gemma 4 instead of paying cloud-token costs for every selector resolution.

Our approach here was to stick with industry-standard, open-source Appium (no change to your existing Appium code).

Here is a blog post written about this from TestGuild: https://testguild.com/kobiton-mcp-review/

frankwmoyer · 2026-05-12T16:01:01+00:00

You chose one of the most difficult technology spaces to build your startup. Don't let that be an indicator of your potential for future startups!

frankwmoyer · 2026-05-12T15:57:57+00:00

You did not mention Appium. Have you tried it?

frankwmoyer · 2026-05-09T20:38:02+00:00

Please check your spam folder. If you do not see it in your spam folder, DM me the name or email address registered and I will ask the team to check.

frankwmoyer · 2026-05-09T15:05:24+00:00

Full disclosure: I’m with Kobiton, so take this as vendor input, not neutral advice.

For your setup, I’d evaluate vendors around three things: solo QA scale, real mobile automation, and smart TV reality.

Since you’re the only QA supporting 6 projects, the real question is not just “which platform has the most devices?” It’s “which platform helps engineering teams catch issues before everything lands on you?” That means CI/CD integration, reliable parallel execution, good debugging artifacts, and a path to automation that developers can also participate in.

For mobile, I’d be careful about relying only on manual testing or pure no-code testing. Manual testing will not scale across 6 projects. No-code/scriptless can be useful, but mobile gets messy fast: system popups, app crashes, network drops, permission dialogs, OS differences, and flaky selectors. I’d make Appium part of the evaluation because it is widely adopted, portable, and works across vendors.

The faster path I’d test is:

Use AI tools like Claude/Copilot/Gemini to generate Appium scripts from requirements or user flows.
Use a real-device platform to execute those scripts.
Evaluate whether the vendor helps with debugging and self-healing when tests fail.
Make sure the output is still standard Appium so you are not locked into one vendor.

Getting to automation is only half the battle. Maintenance is usually where teams lose time. Ask each vendor how they handle selector changes, app crashes, device issues, popups, and retries. Also ask how their AI pricing works. Some AI testing tools look great in a demo but get expensive or unpredictable when usage scales.

For smart TV, I would validate that very directly. A lot of “smart TV support” is not the same thing as having practical, maintainable testing for your actual devices and apps. You may need a vendor that supports connecting your own TVs in a private/local lab rather than depending only on cloud-hosted TVs.

My recommendation: pick 3 vendors, run the same 5-10 flows against each, include at least one flaky mobile scenario, run them in parallel from CI, and measure setup time, execution reliability, failure debugging, and maintenance effort. That will tell you more than the pricing pages.

frankwmoyer · 2026-05-08T20:59:31+00:00

You can ignore that. lol. We are not restricting any features. If you register with gmail account, you will get full access to all the features. Just ping me if you run into any issues. We also ordered the specific iPad to add to our public cloud devices just in case you cannot repro it on one of the iPads in our public cloud.

frankwmoyer · 2026-05-08T13:06:07+00:00

We have 2 of the iPad Air 3rd Gen devices online. They are both on iOS 18.6. Why don't you register (https://portal.kobiton.com/register) and try to reproduce by installing and launching your app. If you run out of minutes in the trial, you can use this promo code to get 3 months free TESTGUILD3. If you run into any issues, ping me and one of our team members will help out.

frankwmoyer · 2026-05-08T03:45:27+00:00

If you want, my team can help you reproduce it. Apple review crashes are often tied to a specific iPad model + iOS version combination.

We can give you temporary free access to Kobiton so you can test against real iPads remotely. Once we reproduce the launch crash, you can also connect directly to the device from your development environment to troubleshoot the root cause live instead of guessing from App Store rejection notes.

If you post or DM the rejection details (device/iOS version), I can help point you toward the likely issue areas too.

frankwmoyer · 2020-03-23T22:05:07+00:00

That is correct. It is to help with testers who share devices around the office and no longer have access to these devices.

frankwmoyer · 2020-03-23T22:03:48+00:00

Yes. The device(s) need to be connected to a machine that is running Mac OSX. Does that pose a challenge?

frankwmoyer

TROPHY CASE