Automated test execution can become complex if your tests need to run across a shared pool of devices. Your Selenium test may need a particular browser and OS. Whereas an Appium run may require a specific device or version.<\/p>\n\n\n\n
And as these requirements multiply with increase in test suites, you need to coordinate requests without turning device and environment management into another task for your QA team to handle.<\/p>\n\n\n\n
Quantum Grid, Selenium Grid, and HyperExecute solve this problem. But which one is right for your team? We\u2019ll discuss that in this blog.<\/p>\n\n\n\n
Check out how Quantum Grid can simplify device routing and parallel test execution. Request a free TestGrid trial<\/a>.<\/p>\n\n\n\n Quantum Grid works like a gateway between your existing automation framework<\/a> and the available infrastructure. It\u2019s compatible with standard Appium and WebDriver clients.<\/p>\n\n\n\n Rather than connecting your tests to individual Appium node URLs, you can use a single hub endpoint to route your sessions based on capabilities, dynamically allocate matching devices, conduct parallel execution, and queue requests when device capacity is unavailable.<\/p>\n\n\n\n Selenium Grid enables you to run WebDriver tests across multiple machines, browsers, and operating systems. Its Router receives your requests and sends new sessions to the New Session Queue.<\/p>\n\n\n\n The Distributor matches those requests to available Node slots as per capabilities. Grid supports Standalone, Hub-and-Node, and fully distributed deployments which can help your teams to scale execution across multiple Nodes.<\/p>\n\n\n\n Also Read<\/strong>: Mastering Parallel Test Execution Using Selenium<\/a><\/p>\n\n\n\n LambdaTest HyperExecute is a test orchestration platform which distributes tests across concurrent virtual machines with strategies like AutoSplit and Matrix.<\/p>\n\n\n\n AutoSplit uses test discovery and execution history to distribute tests. Matrix runs tests across specified environment combinations. HyperExecute also has dynamic allocation capability so you can distribute test cases<\/a> among available parallel tasks during runtime.<\/p>\n\n\n\n The test execution usually starts when the Appium or WebDriver client sends a session request with its required capabilities and authentication details. The platform then assesses those requirements against available execution capacity and begins the session on a matching device.<\/p>\n\n\n\n In case the selected device reaches its session limit, the request enters the FIFO queue until a matching execution slot becomes available. When a particular execution completes or the session times out, the next queued request proceeds.<\/p>\n\n\n\n Your test request first enters through the Router and is placed in the New Session Queue. The Distributor then polls the queue, checks the requested capabilities against free Node slots, and attempts to create the session on a matching slot.<\/p>\n\n\n\n If the matching slots are busy, your request stays queued for another attempt. After the session is created, the session-to-Node mapping is stored. This allows the next commands to be routed directly to the Node running that session.<\/p>\n\n\n\n Learn More<\/strong>: Selenium Grid Tutorial: Architecture, Selenium Grid 4 Setup & Parallel Testing<\/a><\/p>\n\n\n\n The execution flow here generally starts with the HyperExecute YAML which defines the environment, execution strategy, test discovery, and resource allocation.<\/p>\n\n\n\n The CLI then submits this configuration and test scripts to HyperExecute. Then it distributes your tests across parallel execution nodes.<\/p>\n\n\n\n When you enable AutoSplit, your tests are divided according to the configured concurrency. Matrix mode, on the other hand, creates tasks from defined test environment<\/a> combinations. You can easily view your execution progress in the HyperExecute Dashboard.<\/p>\n\n\n\n Quantum Grid<\/strong><\/p>\n\n\n\n Quantum Grid allows you to run multiple sessions simultaneously across available devices. When your tests are launched from CI, local machines, or parallel threads, they can all use the same Quantum Grid hub.<\/p>\n\n\n\n When there\u2019s a matching device available, it\u2019s allocated dynamically, so that workloads targeting different devices can run concurrently rather than waiting for one another unnecessarily.<\/p>\n\n\n\n Selenium Grid<\/strong><\/p>\n\n\n\n Selenium Grid helps you run many tests concurrently by distributing WebDriver sessions across multiple Node machines and their available slots. The Distributor maintains the available slot model and matches incoming session requests against slot capabilities.<\/p>\n\n\n\n This lets your team execute tests against different browsers<\/a>, browser versions, operating systems, or multiple instances of the same browser in parallel.<\/p>\n\n\n\n HyperExecute<\/strong><\/p>\n\n\n\n HyperExecute leverages multiple orchestration strategies for executing parallel tests. Your tests can be divided across multiple concurrent virtual machines through the Autosplit mode. You can also create tasks from defined parameter combinations via Matrix.<\/p>\n\n\n\n And enabling dynamicAllocation allows you to assign test cases to workers as they become available.<\/p>\n\n\n\n Quantum Grid<\/strong><\/p>\n\n\n\n Your team has the flexibility to specify the platform, OS version, tags, or a specific device ID. But if you provide no device ID, Quantum Grid selects an available device matching the requested criteria.<\/p>\n\n\n\n It also supports separating real physical devices from virtual devices like emulators and simulators through the platformTarget <\/strong>capability.<\/p>\n\n\n\n Selenium Grid<\/strong><\/p>\n\n\n\n Since Selenium Grid<\/a> allocates sessions through Nodes and their available slots, each Node registers its slots and their capability profiles. When you request a session, the Distributor compares the capabilities requested with those which are supported by available slots.<\/p>\n\n\n\n After that, it assigns the session to a suitable Node. You can also configure Nodes with different browsers, browser versions, operating systems, and custom capabilities.<\/p>\n\n\n\n HyperExecute<\/strong><\/p>\n\n\n\n Here, you use the runson<\/strong> feature to determine which operating system you want to execute your tests on. It supports Linux, Windows, and macOS environments.<\/p>\n\n\n\n The Matrix mode lets you define combinations of operating systems, browsers, browser versions, and other parameters for cross-environment execution.<\/p>\n\n\n\n Learn More<\/strong>: Why Real Device Testing Clouds are Essential for Today\u2019s Enterprises<\/a><\/p>\n\n\n\n Quantum Grid<\/strong><\/p>\n\n\n\n Parallel execution has a limit. If any of the matching devices reaches session capacity, Quantum Grid, rather than failing the request, queues the next request. The best part is you can control queue management.<\/p>\n\n\n\n You can disable queuing when an execution should fail rather than wait. A configurable queue timeout determines how long a session can remain pending. The default timeout is 120 seconds, with a maximum of 30 minutes.<\/p>\n\n\n\n Selenium Grid<\/strong><\/p>\n\n\n\n This platform places your new session requests in its New Session Queue in FIFO order. The Distributor first checks the queue to see if there are any requests and then matches them against available Node slots.<\/p>\n\n\n\n In scenarios where all matching slots are busy, the request is returned to the queue for another attempt. You have the option to set up timeouts and retry intervals for queued requests. The default request timeout is generally 300 seconds. Requests which exceed this timeout are rejected.<\/p>\n\n\n\n HyperExecute<\/strong><\/p>\n\n\n\n HyperExecute queues your tests when the available parallel execution capacity is exhausted. Each of your parallel test executions consumes one HyperExecute license. So, if your trigger tests with 10 available licenses, 10 execute concurrently and the remaining 40 are queued.<\/p>\n\n\n\n After the running tests finish, queued tests are dequeued and moved to the running state. The dashboard shows you the number of tasks currently running in parallel and the ones waiting in the queue.<\/p>\n\n\n\n Learn: <\/strong>Run Selenium Tests on TestGrid\u2019s Fully Managed Selenium Grid<\/a><\/p>\n\n\n\n Quantum Grid<\/strong><\/p>\n\n\n\n Quantum Grid connects your existing Appium or WebDriver framework to available devices and execution slots in TestGrid.<\/p>\n\n\n\n Rather than configuring individual Appium node URLs, your tests use a common Quantum Grid endpoint, while the gateway handles device matching, session routing, and queueing based on the capabilities supplied with each request.<\/p>\n\n\n\n This means the orchestration logic for selecting an available matching device and handling temporary capacity constraints doesn\u2019t need to be built into each individual test.<\/p>\n\n\n\n Selenium Grid<\/strong><\/p>\n\n\n\n In Selenium<\/a> Grid, you have to provision and configure the infrastructure which hosts the Grid components and Nodes. Nodes can run on different machines and operating systems and register with the Distributor.<\/p>\n\n\n\n You can deploy Selenium Grid as Standalone, Hub-and-Node, or fully distributed. Nodes can also run sessions in Docker containers or relay commands to external WebDriver services.<\/p>\n\n\n\nUnderstand What Each Does<\/strong><\/h2>\n\n\n\n
Quantum Grid: A central hub for managing test sessions<\/strong><\/h3>\n\n\n\n
Selenium Grid: Distributed test execution infrastructure<\/strong><\/h3>\n\n\n\n
HyperExecute: Broader orchestration layer<\/strong><\/h3>\n\n\n\n
How Each Solution Handles Test Execution<\/strong><\/h2>\n\n\n\n
Quantum Grid<\/strong><\/h3>\n\n\n\n
Selenium Grid<\/strong><\/h3>\n\n\n\n
HyperExecute<\/strong><\/h3>\n\n\n\n
Key Capabilities Comparison<\/strong><\/h2>\n\n\n\n
1. Parallel test execution<\/strong><\/h3>\n\n\n\n
2. Device and environment allocation<\/strong><\/h3>\n\n\n\n
3. Queue management<\/strong><\/h3>\n\n\n\n
4. Infrastructure management<\/strong><\/h3>\n\n\n\n