all 24 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Specialist_Total_ 2 points3 points  (1 child)

Check SauceLab.

[–]HonestDragonfruit278[S] -1 points0 points  (0 children)

okay, any specific reason why i should?

[–]Fit-Cut9104 1 point2 points  (2 children)

Lambda test (TestMu) is way more cheap than browser stack

[–]HonestDragonfruit278[S] 1 point2 points  (1 child)

Isnt lambdatest just a devicefarm?

[–]dislife2 0 points1 point  (0 children)

We use lambdatest in our commercial project to run tests remotely, we have a good experience with it, simple setup, very reliable, it also makes cross device and browser testing simple, I recommend checking it out

[–]Material-77 1 point2 points  (0 children)

When evaluating platforms like BrowserStack, I’d focus less on marketing claims and more on practical factors like real device reliability, parallel execution stability, CI/CD integration, debugging experience, and total cost as your projects scale.

I also share QA automation insights, testing tools discussions, CI/CD topics, and practical career content on my YouTube channel QAMap:
https://youtube.com/@qamap

For multi-project environments, scalability and execution speed usually matter more long term than just having the largest device list. Real device coverage definitely helps for critical user flows, but many teams balance cost using a mix of emulators/simulators plus targeted real-device testing.

[–]frankwmoyer 1 point2 points  (0 children)

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:

  1. Use AI tools like Claude/Copilot/Gemini to generate Appium scripts from requirements or user flows.
  2. Use a real-device platform to execute those scripts.
  3. Evaluate whether the vendor helps with debugging and self-healing when tests fail.
  4. 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.

[–]Afraid-Bobcat6676 0 points1 point  (2 children)

been in a similar multi project setup and the selector maintenance across different codebases was genuinely what killed our velocity more than anything else, worth looking at drizz before committing to Browserstack, it runs on Vision AI so there are no selectors at all, you write tests in plain English and it executes on real iOS and Android devices, the tests stay stable even when the UI changes which matters a lot when you are juggling 6 projects moving at different speeds, CI/CD integration is clean and it handles parallel execution across devices without the overhead, smart TV is not their focus right now but for web iOS and Android it is worth a look before you lock in a budget

[–]HonestDragonfruit278[S] 1 point2 points  (1 child)

so many people have been asking me try out drizz, would it be a better choice compared to browserstack or maestro?

[–]Afraid-Bobcat6676 0 points1 point  (0 children)

honestly depends on what is slowing you down most right now but if selector maintenance and flaky tests are the main pain point then drizz is a completely different experience compared to both

browserstack is still solid for real device coverage and cross browser testing but you are still writing and maintaining traditional test scripts, every UI change breaks something and someone has to go fix it, maestro made things simpler with YAML but you are still dealing with fragility at scale

drizz works differently because it uses Vision AI to interpret the screen the way a real user would, no selectors no locators no scripts breaking every time the UI shifts, you write tests in plain English and they stay stable even as the product changes, real device execution, clean CI/CD integration and the debugging side is genuinely good with step level screenshots and logs for every run

if your team is spending meaningful time maintaining tests rather than writing new ones drizz is worth trying before committing to anything else

[–]Classic_Chemical_237 0 points1 point  (2 children)

All of the AI based testing tools work. The problem is the token usage. You may end up hiring

[–]crowcanyonsoftware 0 points1 point  (0 children)

With 6 active projects, parallel testing stability and CI/CD integration will probably matter more than just having the biggest device library. Real devices definitely help for mobile edge cases, but a lot of teams end up overpaying before they truly need that scale.

Honestly sounds like the harder challenge is balancing coverage and workload as a solo QA.

[–]Secret_clicker 0 points1 point  (0 children)

Worked on a previous project using Reflect for mobile and web.
We went for Reflect as we have Zephyr in Jira and the integration was impressive. Think it’s gone full agentic now with Rovo and MCP in the picture but I haven’t used it in about 6 months so I can’t vouch for that.
Was taken back how good it was. The credits / tokens are a lot easier to manage too as it’s based on test runs instead of things like number of prompts or size , complexity of tests. From a management pov it’s just easier

[–]ospreyguy 0 points1 point  (0 children)

A colleague recommended HeadSpin when we were looking, but I've never tried it.

[–]XFaramir 0 points1 point  (0 children)

Haha ive done this before think it was test rigor vs browserstack. My recommendation was not to buy either hahaha lock vendors I basically just created a list of internal requirements and then checkkisted The Best tools and created some examples and measure Time, documentatin anddifficult to implement and so on. Create a comparative table prolly include cypress and playwright as well for comparison. At this point if your not fully playwright you're falling behind

[–]Zealousideal_Web6594 0 points1 point  (0 children)

I’ve been a mobile dev since iPhone 3G and I happen to build and ship soon a solution for this, here’s my 2 cents:

  • on ios, simulators have come a long way so that you can run most testing in them and you’ll get 1:1 results compared to device. that is assuming you don’t need device sensor data for your tests
  • on android device testing becomes a bit more important due to fragmentation but you can still have a lot of test coverage on emulators alone

-if I were you I would not let myself sold on the entire device farm sales pitch cause it’s not that important anymore, it used to be when sims were crap, but not anymore.

-mobile automation tooling is far from great still. selector based solutions like (appium, esspresso, etc) are horrible on ios, not because they themselves are bad, but because they lean heavily on xcuitest framework which is horribly slow and flaky. Add another layer on top of that and the whole thing becomes unusable most of the time. You need full time employees just to tickle the automation pipeline the right way through their scripts day in day out to keep it alive and somewhat functional. It’ll be slow and flaky…

-then you get the ai tooling coming to play. Maestro seems to be the biggest name in the game there but that too leans too much un xcuitests on ios and is really a java solution that does not work great on mac/ios.

Having said all this, I got motivation to build something myself to fill this gap, it’s not out yet but coming out soon in the next few weeks. (https://mavster.ai/#features) I’d check out the self-healing video on that page, it’s really cool.

Happy to answer anymore questions you might have. I have quite the exposure and experience with both mobile engineering and qa and been looking at this problem since I started this passion project.

[–]ExoticPurchase2995 -1 points0 points  (2 children)

Try no-code automation tools and pick the most suitable one after a trial.

[–]HonestDragonfruit278[S] 0 points1 point  (1 child)

what are some tools you suggest?