Queue your tests

With queuing, you can launch an additional number of parallel tests with different device configurations that will be queued in a sequence. For instance, if you want to run 5 additional tests, apart from your subscribed limit of, say, 2 parallel tests, we will queue the additional 5 tests until one of the 2 initial tests finish, and a slot is available for execution. With queuing, you don’t need to worry about managing your test pipeline - we automatically take care of scheduling and execution for you.

With this feature, accounts up to 5 parallel tests can queue 5 tests. Beyond 5 parallel tests, an equivalent number of tests will be queued. For example, if you have 2 parallel tests for your account, you can queue up to 5 more tests. If you have 200 parallel tests, you can queue up to 200 more tests.

Scenarios where queuing helps

Queuing is enabled by default by BrowserStack to ensure you don’t have to worry about managing the test execution on your end. This helps especially in the following scenarios:

• When you have multiple projects / PRs to test using the same BrowserStack account. If the other project is already running at full capacity, your new tests are better off in a queue than getting discarded altogether.
• When you have multiple users in your team who use the same BrowserStack account for their projects. Rationing of parallel tests across teams can be inefficient - instead queuing can help you manage the test executions in a simpler manner.
• If the number of total test cases is within the queue limit and if you don’t want to write some logic to dispatch tests, you can just submit all your tests to BrowserStack, and we will automatically manage the test runs for you.

In a few rare cases, BrowserStack will automatically put your tests in a queue for a short period of time so your other tests can run first. This is usually when the device and OS configurations you want to run your test on has a long start-time delay (either because of peak usage or booting up time). This makes way for the next test which can be quickly run - thus reducing the overall time taken to run your tests. The previously queued test will be automatically dequeued and run whenever a slot becomes available.

How test queuing works

Queues are managed at a user level and not at an organization level. This approach grants the allotted queues to each user in the organization, thus letting tests be added to the queue when all parallels are in use.

To understand the issue with managing queues at an organization level, consider this example, where a user1 in an organization uses all allocated 5 parallels and 5 queues. Whenever user1 polls the Plan API using their BrowserStack credentials, both the parallel and queues will always appear occupied. As the queue always appears occupied, user2 loses an opportunity to push their tests in the queue.

BrowserStack allocates the queues, which is 5 in this example, at a user level to avoid this issue. Both user1 and user2 are allocated 5 queues each. When user2 polls the Plan API, the response shows how many of their queue count the user consumed. This approach allows user2 to queue their tests irrespective of whether all parallels are in use or not.

The ‘Queued’ tracker on App Automate Dashboard also shows the number of queued tests at user level and not at an organization level.

Alternatives

You can also choose to manage the dispatching of tests at your end with/without utilizing the queueing functionality. You can use the Plan API to find out the parallel sessions running, the max allowed sessions, queued sessions and max allowed queued sessions for your plan and dispatch tests accordingly.