Selenium Grid in the Cloud Reviews

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.

My main use case for using Selenium Grid in the Cloud is cross-browser and parallel test execution to reduce the regression testing time and improve the browser compatibility coverage. I use it primarily for automating regression testing across multiple browsers and operating systems as part of my CI/CD pipeline.

During regression testing, I trigger my automated Selenium test suite through Jenkins, which connects to a cloud-based Selenium Grid in the Cloud platform and the test runs in parallel on multiple browsers and OS combinations such as Chrome on Windows, Firefox on Linux, and Safari on Mac OS. This helps me quickly identify browser-specific issues and significantly reduces execution time before releases. In my workflow, I mainly use Selenium Grid in the Cloud for large-scale regression testing whenever a new build is deployed to the QA or staging environment, and my CI/CD pipeline automatically triggers this automation through Jenkins, distributing the tests across multiple cloud-hosted browser environments in parallel.

A recent example I can share is that I use the same test suite simultaneously on Chrome, Firefox, Edge, and Safari across different operating systems such as Windows and Mac OS. In some cases, I also execute the tests on real mobile devices to validate responsive behavior and critical user flows, which helps verify that the application behaves consistently for users regardless of their browser or platform.

I use the platform's built-in features such as session recording, screenshots, logs, and debugging tools whenever my tests fail, making it easier for both my QA team and the development team to analyze failures and quickly identify browser-specific issues. The cloud setup also scales well during major releases when I need to execute larger automation suites or temporarily increase the parallel run.

I personally appreciate several features of Selenium Grid in the Cloud, especially the parallel test execution feature, which is one of the biggest advantages in the ability to run multiple test cases simultaneously across different machines and browsers. Instead of executing tests sequentially on a local machine, it helps me identify the root cause of issues. I also appreciate the cross-browser and cross-platform testing feature because cloud platforms provide access to thousands of browser and operating system combinations without the need for maintaining physical infrastructure internally, allowing my team to validate applications on environments from a single setup.

Additionally, I value the real device testing feature because modern cloud Selenium providers offer testing on real mobile devices and desktop environments instead of relying only on emulators and simulators. Furthermore, I value the detailed debugging and reporting tools in Selenium Grid in the Cloud, as most platforms provide session recording, screenshots, Selenium command logs, browser console logs, network logs, and failure analytics, making it easier to identify flaky tests and browser-specific failures or front-end issues.

Out of the features I mentioned, the one that has made the biggest impact on my workflow is definitely parallel test execution in Selenium Grid in the Cloud environment. Before moving to cloud-based setups, my regression suite used to run sequentially on limited local machines, which made the testing cycle very time-consuming, especially before releases, to the point where a full regression would take several hours, slowing down feedback from both my QA and development teams. Now with parallel execution, I can distribute tests across multiple browsers and operating systems simultaneously. For example, the same automation suite can run at the same time on Chrome, Firefox, Edge, and Safari across Windows and Mac OS environments, significantly reducing execution time and improving release efficiency because I receive test results much faster and can identify issues earlier in the deployment cycle.

Another major benefit is how well this fits into my CI/CD workflow, as faster automated tests mean developers receive quicker feedback on failed builds or browser-specific issues, which helps reduce bottlenecks during sprint releases and hotfix deployments. Plus, the scalability of this feature allows me to temporarily increase the number of parallel sessions during critical releases without provisioning additional hardware or maintaining extra Selenium nodes internally, making automation significantly more reliable and easier to manage compared to an on-premises setup.

Selenium Grid in the Cloud has positively impacted my organization by improving testing efficiency, accelerating release cycles, and reducing infrastructure management overhead. Before adopting a cloud-based setup, I spent significant effort maintaining local system nodes, browser versions, virtual machines, and execution environments, which often consumed valuable QA and DevOps time and occasionally caused instability in the automation runs. After moving to a cloud-based Selenium Grid in the Cloud platform, the overall automation process became much more scalable and reliable, with one of the biggest organizational benefits being the reduction in regression testing time through parallel execution, as a large automation suite that previously took several hours can now complete much faster, allowing my QA team to provide quicker feedback to developers and support faster sprint deliveries and production releases.

After using Selenium Grid in the Cloud for more than two and a half years, I feel that there are areas that could be improved to enhance usability, stability, and efficiency for enterprise QA teams. One area for improvement is test execution stability and flaky session handling, as intermittent failures can sometimes occur during large automation suites due to network latency, browser session instability, or temporary environment issues in the cloud infrastructure rather than actual application defects. Better automatic retry mechanisms and faster failure categorization alongside more transparent infrastructure health monitoring would help teams quickly distinguish between genuine failures and environmental issues.

Another improvement could be execution speed consistency, as although parallel execution significantly reduces overall running time, test startup times and browser session initialization can occasionally vary depending on server loads and region availability. More optimized resource allocation and faster browser provisioning would further enhance execution reliability, especially for very large CI/CD pipelines where every minute counts. Additionally, real device testing can also improve in terms of availability and responsiveness during peak usage hours since some organizations rely heavily on specific device-browser combinations and instant access to those environments without queue delays would enhance productivity for release and critical testing.

I believe that better integration and reporting across the DevOps ecosystem would also add value to Selenium Grid in the Cloud. While most cloud platforms already integrate with tools such as Jenkins and GitHub Actions, having a more unified dashboard that combines test analytics, flaky test tracking, release impact analysis, and historical trends would provide stronger visibility for engineering leadership and QA managers. Also, security and compliance controls are important areas for enterprise users, and enhanced support for private cloud environments, stricter data isolation, advanced audit logging, and region-specific execution controls would really help organizations in regulated industries adopt cloud testing more confidently.

I have been using Selenium Grid in the Cloud for the last two and a half years.

In my experience, Selenium Grid in the Cloud is quite stable. I have not experienced any downtime.

The scalability is also good. I am able to scale whenever there is high traffic in my system for the usage of my features, so I do not have any problems with scalability.

The customer support for Selenium Grid in the Cloud is very knowledgeable and they are always happy to help. Sometimes their responses are delayed, but that is acceptable due to regional timing differences, so I am satisfied with the customer support.

I previously used robotic process automation to automate my test cases, but since it is a non-coding environment and I have always been interested in coding from the start of my career, I switched to Selenium Grid in the Cloud so I could code and test my features and the platform.

Regarding pricing, setup cost, and licensing for Selenium Grid in the Cloud, the initial setup cost is relatively low compared to building and maintaining an internal Selenium Grid infrastructure since cloud providers manage the browser nodes, virtual machines, device labs, scaling, and maintenance. This avoids the upfront investment required for physical hardware and significantly reduces the operational complexity for the QA and DevOps teams.

My main advice for organizations considering Selenium Grid in the Cloud is to clearly understand their automation goals, execution scale, and long-term testing strategy before selecting a platform or scaling usage. One important recommendation is to start with a pilot implementation instead of migrating everything immediately, beginning with a smaller regression suite or a few critical workflows to evaluate execution stability, browser coverage, CI/CD integrations, reporting quality, and overall ease of use. This approach helps teams identify practical limitations and estimate infrastructure usage and cost before broader adoption.

I can provide some rough estimated metrics related to ROI. The most measurable ROI comes from the reduction in regression execution time, as before moving to cloud-based parallel execution, my regression cycle typically took around five to six hours on limited local infrastructure, but after implementing Selenium Grid in the Cloud with parallel execution, I reduced the execution time to approximately one to two hours, translating to a sixty to seventy percent reduction in regression testing time. Additionally, I experience better utilization of QA and DevOps resources, so overall, Selenium Grid in the Cloud introduces subscription costs and operational savings, execution efficiency, scalability, and reductions in infrastructure management efforts, delivering a strong long-term ROI for my organization.

From a licensing perspective, most cloud Selenium Grid in the Cloud platforms follow a subscription-based model where pricing is driven primarily by the number of parallel test sessions, real device usage, team size, and user access. In my case, the biggest pricing factor is parallel execution capacity, as higher concurrency directly impacts regression execution speed, which is provided by BrowserStack and other providers based on the number of parallel sessions available.

Before choosing Selenium Grid in the Cloud, I evaluated several options in the market, first considering maintaining a fully hosted Selenium Grid infrastructure internally. While this approach offered direct control over the environment and potential lower recurring subscription costs, I evaluated multiple cloud-based testing platforms such as BrowserStack, Sauce Labs, and LambdaTest.

Overall, Selenium Grid in the Cloud can provide tremendous value when implemented thoughtfully, especially for teams aiming to scale automation, improve release speeds, and reduce infrastructure management overhead. I would rate this product an eight out of ten.

Our main use case for Selenium Grid in the Cloud is running the automation test cases which we have, as running that locally is not a possibility because there are too many, and we want to run them in parallel in a reliable way, making it a must for us to utilize Selenium Grid in the Cloud.

Selenium Grid in the Cloud has positively impacted my organization by decreasing the time to test and deliver in production, significantly improving our DORA metrics. We are able to run more test cases on the same application and before using Selenium Grid in the Cloud, the time taken would have been prolonged, limiting our ability to test on different versions or browsers concurrently. This improvement helps in decreasing incidents, increasing customer satisfaction, and significantly reducing the time to deployment and testing, thereby positively impacting my organization.

The best features Selenium Grid in the Cloud offers include the capability to run test cases in parallel, and we implement customizations for identifying flaky tests or tests that are not running fine. Whenever test cases fail, we receive full logs and screenshots, which help us significantly. Selenium Grid in the Cloud assists us in parallel execution and enables us to distribute the workload effectively; if the workload is light, we can free up machines, and if it's heavy, it scales up automatically with multiple machines. It also allows us to test our applications across various versions of the same browser and on different browsers, as well as test mobile websites to see performance across different platforms, features that are definitely helpful for us.

We manage the tests on Selenium Grid in the Cloud based on the rankings, so we do ranks and decide when we are going to run based on which intervals. For some applications, we maintain an Excel sheet in which we do the ranking and the intervals, while in other cases we have config map files that categorize particular test cases based on their priority. We write the priority using annotations as well, which is how we manage everything on Selenium Grid in the Cloud.

Sometimes Selenium Grid in the Cloud requires manual intervention for very long-running test cases, which can get stuck and block the machine. We attempt to set up some customizations that facilitate automatic failure, and giving alerts at that moment would be really beneficial for debugging. This expectation of features in Selenium Grid in the Cloud is important to reduce our manual workload; having more customization options without switching to a paid version would be advantageous.

There are areas where Selenium Grid in the Cloud can be improved; we need to undertake many customizations on our end. The iteration speed for new features should be faster, incorporating market feedback effectively. Additionally, enhancements around Kubernetes could improve our configuration ease, and features like KEDA could optimize the upscaling and downscaling processes. Opportunities for integrating observability metrics through OpenTelemetry also exist, which would be useful for analysis. I would appreciate seeing more rapid iterations aligned with industry advancements, and incorporating AI features like chatbots for information retrieval would be beneficial.

There are smaller improvements needed as well; for instance, better test management integrations that allow direct session pushes to TestRail, Xray, or Allure would be great. Notifications to teams via Slack or PagerDuty alerts regarding issues will also aid in informing developers about failures. Implementing AI-based resource prediction capabilities would provide valuable insights into resource utilization based on past run data, which would certainly enhance our operations.

I've been using Selenium Grid in the Cloud for more than six years.

Regarding the scalability of Selenium Grid in the Cloud, it is not particularly scalable when configured manually, as we need to set up several custom solutions to enhance scalability.

The customer support for Selenium Grid in the Cloud is decent, but I would not describe it as great since we have to handle many tasks ourselves.

We did not use a specific solution prior to adopting Selenium Grid in the Cloud; however, we tried various paid tools such as BrowserStack, which performed well but was not cost-effective or suitable for running high-scale tests. Thus, we shifted to the open-source option and configured everything ourselves.

Before choosing Selenium Grid in the Cloud, we evaluated several other options, including paid tools like BrowserStack, Sauce Labs, and Perfecto, but found them lacking for our needs. We also checked self-hosted options such as Selenide and Moon before deciding to set up Selenium Grid in the Cloud on our public cloud.

My advice for others considering Selenium Grid in the Cloud is that if you have a capable DevOps engineer to manage scalability issues and can operate the platform independently, the open-source solution is the way to go. However, if you prefer low-maintenance options, I recommend looking into paid solutions like BrowserStack that offer significant benefits and CI/CD integrations. I would rate this product a seven out of ten.

My main use case for Selenium Grid in the Cloud is to run tests in a way that is not dependent on any particular platform.

This approach has worked well, with the main benefit being that I can run tests in parallel. Since I have containerized the test with Java as the entry point, the image size is kept as small as possible for low-cost shipping to remote machines.

The entire CI/CD pipeline is configured in Jenkins, leveraging EC2 instances to run our tests.

The best features Selenium Grid in the Cloud offers are scalability and running tests in parallel.

The Docker-based approach allows me to spin up a specific Chrome version easily to run those tests, making it an adaptable solution for whatever versions of the browser I want.

Selenium Grid in the Cloud has positively impacted my organization by being more cost-friendly and providing better scaling and speed of execution than the legacy way of running things.

One way Selenium Grid in the Cloud can be improved is by having periodic releases or a ready-made Docker image with Selenium Grid in the Cloud to skip the manual setup.

I often see challenges in visibility, as sometimes I am unable to see the logs, which would be a point of improvement.

I think Selenium Grid in the Cloud can be refined and incorporate AI features, as AI could bring more intuitiveness to the grid and enhance its usability.

I have been using Selenium Grid in the Cloud for close to three to four years.

I personally have not faced many issues with stability; there are occasional failures that can be attributed to either test case issues or infrastructure issues.

The scalability of Selenium Grid in the Cloud is pretty good since I can spin up any number of containers with just one command.

Overall, customer support is good; I have not encountered many issues that required direct interaction with customer support.

Previously, we used the legacy way with around ten to fifteen VMs configured in our private network, facing many challenges that are now mitigated with the Dockerized approach and EC2's flexibility.

Before choosing Selenium Grid in the Cloud, we ran tests locally to prove that the Dockerized-based approach worked as intended before extending to AWS.

I can definitely comment on time saved; earlier, tests took close to three to four hours when run sequentially, but now it is drastically cut down by more than fifty percent, making it about two hours for end-to-end tests.

I would advise others to consider Selenium Grid in the Cloud as a great solution since it allows for hosting and scaling as needed. I give this review an overall rating of nine.

Parallel testing is my main use case for Selenium Grid in the Cloud, which I use extensively. I have approximately 5,000 test cases, and I need to reduce execution time by running tests on different machines to enable parallel execution and decrease the overall time required.

I use Selenium Grid in the Cloud through BrowserStack, where I have access to real devices to execute those test cases and reduce time. The recordings and logs provided have been helpful for debugging issues.

Recordings are the best features Selenium Grid in the Cloud offers for me, and they are helpful for debugging issues. Having the recording of the execution is sufficient for my needs.

Selenium Grid in the Cloud has positively impacted my organization by improving execution time. Daily, I am able to save five to six hours of execution time, which has helped considerably.

Currently, there are no improvements I would suggest for Selenium Grid in the Cloud, as what I am using has been sufficient for me. I will share any issues or improvement requirements in the future if they arise.

I have been using Selenium Grid in the Cloud for three years.

Selenium Grid in the Cloud is stable; however, I sometimes face challenges, but overall it is almost stable.

I am not certain about the scalability of Selenium Grid in the Cloud, but I think it would be better if there were CI pipeline integration with Selenium Grid. With cross-browser devices, it could be better if I could use cross-platforms incorporating both mobile and web.

The customer support for Selenium Grid in the Cloud is good, as they respond within 24 hours. I would rate the customer support an eight out of ten.

Previously, I had not implemented Selenium Grid and just ran tests normally. After using Selenium Grid in the Cloud, it has helped considerably.

Before choosing Selenium Grid in the Cloud, I found a few alternative solutions, including Selenium.

Selenium Grid in the Cloud is deployed in my organization as a private cloud with one server and one Docker instance using AWS, where I execute all test cases.

After implementing Docker and Selenium Grid, I have seen a drastic reduction in execution time, which has helped improve productivity. My advice for others considering Selenium Grid in the Cloud is that they should pursue it, as it can reduce execution time significantly, improve productivity, and allow focus on critical issues. I rate this review a nine out of ten.

My main use case for Selenium Grid in the Cloud is testing the applications that I'm developing in an integrated, user-facing sort of environment. I had set up Selenium Grid in the Cloud on which we were running our application, and we had automated some tests using a common framework. It was Node.js based and we used Selenium Grid in the Cloud to test that across various browsers and various versions of these browsers so that we could ensure compatibility for our end users and also ensure that our app worked as intended.

The best features Selenium Grid in the Cloud offers include being able to test the application from a user perspective. Testing from a user perspective stands out as a feature for me, and I find parallel execution and cross-browser support to be basic—not having those is a deal-breaker for me.

Selenium Grid in the Cloud by itself does not provide any reporting. Mostly it's the frameworks that do that for me. WebdriverIO was the one that we were using, and it allowed us to do reporting while keeping parallel execution and cross-browser support. It also allowed us to scale pretty effectively and gave us debuggability so that we could keep our tests stable.

Selenium Grid in the Cloud definitely saved a lot of time for my organization. We do not have a specific QA team that tested each and every release, so we followed test-driven development. We ensured that tests were written alongside development, and they helped guide our product lifecycle. It definitely reduced costs a lot. Additionally, being able to get the reliability of running the entire test suite at a whim and with each and every release gave us a lot of confidence in each and every release.

Selenium Grid in the Cloud can be improved by providing more ready-to-use solutions and one-click setup. Right now, I had to go through a lot of hoops just to get it set up in a dockerized, containerized environment. Having a single-click sort of solution right in the open-source projects would be a godsend feature.

Being previously in startups, support did not matter as much for Selenium Grid in the Cloud, but integration has definitely been done well because of the W3C standards and very standardized frameworks which implement that. Documentation has definitely been a strong suite for Selenium Grid in the Cloud. However, being open-source, support lacks a lot, which definitely stops a lot of organizations from picking up a solution such as an open-source Selenium Grid. Being open-source, there is no support.

I have been using Selenium Grid in the Cloud for more than six years.

Selenium Grid in the Cloud is as stable as you make it, but overall, we were able to make it pretty stable.

We were able to scale Selenium Grid in the Cloud as per our needs. We did not have to have anything specifically for our needs or do anything specifically. Selenium out of the box does not provide scalability, so because we used some open-source projects which allowed us to do that, we were able to scale it. However, out of the box, I would say it does not rank great on scalability by its own.

I have dabbled in QTP before choosing Selenium Grid in the Cloud, but being a VB Script based and very old framework, it did not make sense to continue with it. Selenium was the perfect framework for our use since our application was web-based.

We saved about an entire team's worth of salaries with Selenium Grid in the Cloud, which came to about 100k per year. The release confidence is difficult to quantify, but the time saved was significant with each release. I would say at least three to four days were saved per release, and we were doing a release every week, if not every two or three days.

Having not had to hire an entire QA team to test each and every release with Selenium Grid in the Cloud definitely saved us about 100k per year in USD. Additionally, we saved a lot on release timelines. For each release, we saved up to two to three days of manual testing effort at the very least. While it is difficult to quantify that in money terms, this was definitely a huge return on investment.

My experience with pricing for Selenium Grid in the Cloud involved just the infrastructure cost, as being open-source, there was no licensing or setup cost.

I looked at Puppeteer for a while before choosing Selenium Grid in the Cloud, but the cross-browser support wasn't there. Selenium provided me the familiarity because I had worked with it before, so it was an obvious choice.

I would advise others looking into using Selenium Grid in the Cloud to get someone who understands it at a grassroots level. You would be in good standing as long as you're testing a web-based application. It does have support for native apps as well, up to a certain extent, especially if you're also using something like React Native for testing across Android and iOS for cross-platform development. It could be great in that as well, but for web-based applications, I would say this is the best tool out there right now. I would rate this product seven out of ten overall.

My main use case for Selenium Grid in the Cloud is to run multiple devices and multiple OS browser combinations. I tested it on mobile devices as well as on laptops and systems. I wanted to specifically run certain sets of browser combinations or different versions of browsers, and we keep doing this because there are high chances that users directly use various browser configurations.

The best features that Selenium Grid in the Cloud offers are scalability and parallel execution. The user interface is very simple. Selenium Grid in the Cloud has positively impacted my organization by enabling fast test cycles, and the setup was very smooth. We have obviously saved both people and money with Selenium Grid in the Cloud.

I believe the main feature that could improve Selenium Grid in the Cloud is providing an easier perspective. The main part is that sometimes the documentation is not clear, and we run into some problems. The UI features of Selenium Grid in the Cloud could be improved so that it will be easier to set up. The documentation side can also be improved.

I have been working in my current field for almost 16 years.

In my experience, Selenium Grid in the Cloud is stable.

The scalability of Selenium Grid in the Cloud depends upon usage.

Sometimes, I may have to reach out for customer support.

Positive

The solution I previously used before Selenium Grid in the Cloud was a standalone solution which we had, and then we made it as a nightly batch run.

Before choosing Selenium Grid in the Cloud, I evaluated many options available such as Sauce Labs, which are quite expensive and licensed. Selenium Grid in the Cloud is quite easy to set up.

My company has a partnership with this vendor as we consume that.

My advice for others looking into using Selenium Grid in the Cloud is that it is a fantastic solution, especially if they already have a cloud setup with the vendor.

Cost-wise depends on various factors.

Selenium Grid in the Cloud has positively impacted my organization by enabling fast test cycles, and the setup was very smooth.

How it is being used depends on the execution. I found this interview very clean, but there were on and off lags, so I think it was because of my internet connectivity or another factor, but overall it was good. I think providing a short poem or haiku that summarizes my review would be really useful. My review rating for Selenium Grid in the Cloud is 8.

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 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.

My main use case for Selenium Grid in the Cloud involves integrating Selenium and Appium tests together. We are integrating them in the same case, running parallel tests, and we are using the BrowserStack platform, which allows us to run in parallel and also access the video records of them.

A specific example of how I use Selenium Grid in the Cloud for one of my projects is when we run our Appium and Selenium tests on LambdaTest while using a video meeting platform in Astrak. For example, we start a video meeting web-to-web, using Selenium on both sides, but if it is web-to-app, we use Selenium with Appium. This setup ensures the video reaches both sides, and the voice can be transmitted, allowing users to chat and control their cameras and audio.

Generally, we can get the video records of the tests, obtain the logs, run parallel tests, and utilize different capabilities, such as starting browsers and accepting permissions like camera and microphone.

The best features Selenium Grid in the Cloud offers include access to different Selenium versions, various browser versions, and the ability to run parallel tests. These are important parts.

These features help my team significantly because we are able to run tests faster and cover more cases. When we run different browsers, we can cover more cases, and running parallel tests allows us to execute tests faster.

One important aspect of the features is that when we face any issues, we can open the video records and logs. This is the main use case for me.

Selenium Grid in the Cloud has had a positive impact on my organization as we are able to run in an isolated area. It helps us because we are not running locally; we are running on Selenium Grid in the Cloud, which allows us to obtain healthier results and find common usage examples when we want to implement anything.

To improve Selenium Grid in the Cloud, I think it is important to integrate desktop recording because we need to use Selenium Grid in the Cloud with desktop applications in some cases. There are limitations that could be addressed with this integration, as we have limitations in the browser offerings.

I have been using Selenium Grid in the Cloud for around five years. I used it before on LambdaTest for around three years, and now I am currently using it again for almost two years.

Selenium Grid in the Cloud is stable.

Regarding scalability, we are able to run more tests easily.

I haven't required customer support at this point. I talked with the BrowserStack team on the Appium side, but I didn't need any help on Selenium Grid in the Cloud side.

I previously used LambdaTest, but not here. I worked directly for the LambdaTest company. I haven't used any other platform aside from LambdaTest and BrowserStack.

Before choosing Selenium Grid in the Cloud, I checked Sauce Labs, and I didn't explore any other options. I focused on LambdaTest.

I have seen a return on investment because it helps us save time. If we don't use the cloud, we need to set up Selenium Grid and other things ourselves, but in the cloud, everything is ready for us, which allows us to save our time.

My experience with pricing, setup cost, and licensing is that I think the price can be improved. The value is high, but for now, we are using it, and our expectation is better.

My advice to others looking into using Selenium Grid in the Cloud is that the logs and video records help us when some cases fail, and running in parallel allows us to save time and obtain results quicker. This is the most important part for me. I give this product a rating of 9.