BrowserStack Automate Parallel Session Limits and Queue Behavior for a Small Test Suite
0 reputation · 19 Mar 2021, 06:52 UTC
BrowserStack Automate runs Selenium WebDriver and Appium tests in parallel, but the number of concurrent sessions is capped by the subscription plan rather than by the suite itself. For a small application with a compact test suite, the goal is to size parallel runs correctly: how many sessions the plan allows, what happens to tests submitted beyond that cap, and whether queued jobs wait in a predictable order or fail.
Two constraints make this hard to plan in advance. Concurrency allowances are plan-specific and can change with pricing updates, so an assumed capacity may not match the current account. Device and browser availability is also dynamic, since a requested device may be in use or unavailable in a region, so queue times can vary between runs. Automate and Live also serve different purposes, scripted versus manual interactive testing, so capacity assumptions should not mix the two products.
What behavior should be expected when submitted tests exceed the parallel session cap, and where can the current allowance be confirmed? Is there a documented way to handle a busy or unavailable device, such as falling back to an alternative, while keeping results comparable across runs?