My main use case for Selenium Grid in the Cloud involves the company I work for, Telstra, which is a large-scale enterprise telecom company. Here we have many capability teams, and each team has its own automation suite. In order to effectively run this automation suite on their need-to-do basis, we use Selenium Grid in the Cloud using AWS Fargate instance, so that each team can use their own container to run their automation scripts without any interference.

I have something else to add about my main use case or something unique about how my team uses Selenium Grid in the Cloud, specifically for doing our automation runs to ensure that the regression suite is intact. The main reason that we use Amazon Fargate is because we feel the APIs are very good to understand the progress of the automation runs.

The best features Selenium Grid in the Cloud offers for my team include containerization, which isolates the run of one team from the other. The maintenance of the instances is pretty easier, so that the team doesn't have to focus more on the infrastructure point of view. Additionally, we ensure that we use resources only on the need-to-go basis, so we are not overusing any resources. When there is no automation run happening, there are no active instances running. This way, we control the cost as well.

Selenium Grid in the Cloud has positively impacted my organization, Telstra, because we provide more importance to security. All the environments in which our automation runs happen are thoroughly scanned by the internal audit team. Using a cloud service like AWS, where we have a proper security mechanism in place, has helped a lot. In terms of productivity, we feel creating images and other tasks on the go has improved the productivity of the run. Cost-wise, most of the resources are used only on our need basis, which has reduced the cost of our QA budget.

There are many improvement areas I feel that Selenium Grid in the Cloud can make.

I have been using Selenium Grid in the Cloud for the past one year, when I joined Telstra.

In my experience, Selenium Grid in the Cloud is stable and has been reliable for my team, as we noticed very few to minimal issues regarding its performance, making us quite satisfied about the tool.

Selenium Grid in the Cloud's scalability has handled increased demand and larger workloads smoothly. It auto-scales or auto-degrades based on the flow, which has definitely helped our costs effectively. There are no blockers during peak release days where the automation runs are effectively used by almost all the teams. It has managed to handle the releases on time without any complaints from teams about the non-availability of instances to run their automation scripts.

Customer support for Selenium Grid in the Cloud has been good. There is a dedicated team that communicates with the cloud provider and they have provided a satisfactory experience.

Negative

I have not had experience using a different solution before Selenium Grid in the Cloud during my time at Telstra. However, in a previous organization, we created a Jenkins agent node setup within the organization itself, using an in-house distribution with a node and agent connection, resembling a master-slave connection.

I have seen a return on investment, as at least 20% of work has been reduced effectively after going for Selenium Grid in the Cloud, which reduces the man-hours required to maintain and manage tasks. This increase in efficiency allows our team to focus on other aspects of automation, including effectively optimizing the CI/CD pipelines.

I did not evaluate other options before choosing Selenium Grid in the Cloud since I joined Telstra and the infrastructure was already in place, so I did not have the chance to explore other products.

Easy maintenance and resource optimization have helped my team significantly, specifically because the automation is pretty less most of the time. We need to effectively use resources, and in that case, setting up our Selenium Grid in the Cloud becomes the best option since we do not run these regression suites on a daily basis. Teams use them on the need-to-go basis, so whenever there is no automation happening, there will not be any instances running, which definitely helped the cost as we do not use the resources. For debugging purposes, there are proper APIs in place that help to track the failures and get them distributed to the mail distribution list.

The other feature I would like to add about Selenium Grid in the Cloud is the availability of resources. Whenever there is a need for a run, there is a container or instance available for us, which ensures that there is no manual overhead required to maintain the resources. I feel we have an effective infrastructure.

I cannot share specific numbers or estimates about time or money saved, but I can definitely say that productivity has improved by at least 20%. We do not have to spend much of our man-hours to maintain the infrastructure of Selenium Grid in the Cloud, which has reduced the number of people in our R&D team who specifically work on infrastructure and instead focus on other areas including effectively creating a common framework and setting up our CI/CD pipeline using the same.

My advice for others looking into using Selenium Grid in the Cloud is to understand its purpose, grasp the concepts and logging mechanism it has, be aware of pricing, and ensure that it matches your requirements and the pricing policies of your organization.

I used Selenium Grid in the Cloud around five to six years ago, and I have more than four to five years of experience with it.

My main use case for Selenium Grid in the Cloud is running parallel execution, and I want to ensure that my test cases run smoothly on a headless browser on a Linux system.

I use Selenium Grid in the Cloud for running my test cases by managing multiple instances for 5,000 to 10,000 test cases that must run on multiple locales. Since the test case count is huge, execution was taking around one or two days. I addressed that challenge by dividing my load across multiple environments, specifically multiple instances of AWS, where I created multiple instances and ran all scripts on individual machines with the power of Linux. This ultimately reduced the execution time to two hours, which was a success story for our execution by using the cloud for parallel testing.

The best features Selenium Grid in the Cloud offers include the hub and nodes setup, where the hub controls everything on a single machine as the main execution center, and nodes act as supportive machines for distributing load. Running test cases in parallel is a major feature. I also explored another tool called Zelenium, which has very stable features for running tests in parallel without any hassle by providing easy-to-run access.

Selenium Grid in the Cloud has positively impacted my organization by significantly reducing execution time. Previously it was taking around 30 to 35 hours, but now it is reduced to two to three hours, which allows more time for decision-making. The ability to collect reports from individual machines and execution data easily is very good, making it a proud moment for us with respect to speed and efficiency improvements.

There are several areas where Selenium Grid in the Cloud can be improved, particularly regarding connectivity issues. There are challenges with scripts getting stuck, which causes nodes to become unresponsive. Exploring features that Playwright has would be beneficial, such as threading of execution and load balancing, which would enhance performance. Furthermore, good integration with the latest tools and AI capabilities is needed for better functionality.

I have been working in my current field for 15 years.

When considering scalability, having a good Kubernetes cluster with an open-source cloud like AWS has fantastic scalability, but a physical structure for execution can be risky and labor-intensive.

I have never tried the customer support. For customer support, I would rate it a six.

Positive

Before choosing Selenium Grid in the Cloud, I created my own solution for my execution needs.

While Selenium Grid in the Cloud had many problems during development, I eventually stopped using it and created a customized solution, which yielded a good percentage of success.

I have seen a good return on investment, especially when skilled employees tackle real business problems. A skilled employee knows the business well. The importance of having skilled resources over generic tools is evident since tooling might not always yield a high success rate.

In my experience, many organizations prioritize open-source technology over pricing or initial setup costs to customize their systems based on needs. There are challenges with existing setups that can introduce rigidity, which makes businesses struggle.

My advice for others looking into using Selenium Grid in the Cloud is to first understand your business scenario and custom needs. Conducting a trial period or proof of concept is essential before fully committing, as it may pose challenges for new businesses.

I always recommend using stable and open-source solutions. Skilled employees are beneficial for reducing costs, but if resources are lacking, investing in initial tools to solve business problems is critical, as finding skilled labor can pose challenges. I would rate this review overall a six.

I run Selenium Grid in the Cloud test cases using Selenium Grid in the Cloud in AWS to increase parallelization in automation test cases.

I have four nodes set up with Selenium Grid in the Cloud in AWS, which gives us a total of around 12 parallel Chrome Edge browsers. We trigger our Selenium Grid in the Cloud test cases from Jenkins in those grids, which executes our test cases.

Execution time depends on how many test cases we have. If our number of test cases is higher, we increase the nodes.

Selenium Grid in the Cloud reduces our execution time by providing more Chrome browsers.

It gives more control over how we want to execute and how many nodes we want to add. We don't have any higher number of limits and can add as much capacity as needed in terms of execution frequency. It provides more flexibility towards the grid on our premises, so we don't have to rely on third-party providers.

Selenium Grid in the Cloud helps us reduce execution time for automation and gives us the ability to deliver faster.

We should have support from AWS or other cloud providers which can help us integrate Selenium Grid in the Cloud more easily.

Selenium should introduce some setting configurations at the grid level with Selenium Grid in the Cloud, which we can configure for increasing or decreasing nodes.

I have used Selenium Grid in the Cloud for around two years.

Selenium Grid in the Cloud is stable.

We can scale very fast with Selenium Grid in the Cloud by adding a number of nodes. If we have a single requirement, we can still operate using Selenium Grid in the Cloud. If we have a large-scale requirement, we can add a number of nodes, which gives large scalability to Selenium Grid in the Cloud.

Selenium Grid in the Cloud is easy to set up and easy to scale. We have full control over the tool and can configure it as we require.

We have seen return on investment as Selenium Grid in the Cloud reduces execution time.

We don't have rough numbers, but it saved 90% of time with Selenium Grid in the Cloud.

There is no pricing for Selenium Grid in the Cloud, as it is open source.

Selenium Grid in the Cloud is open source, so documentation is good and we don't face any issues. The overall review rating for this solution is 8.