The current Grid project is not designed properly for heavy load and does not have a stateful structure. So if the hub crashes, everything starts over. What to do?

You can run your Selenium-based test automation scripts on the browser you want and distribute it with the Selenium Grid project. This is actually a very simple and easy solution.

According to the architecture, thanks to the Selenium grid project, you raise a hub and register different machines to this hub as a node. In this way, the hub directs you according to which browser or operating system you will run. If that node is used by a different test, it will queue you up and continue running the next test when it is finished.

I can hear what the experienced test engineers are saying. That job won’t be that easy. In teams with more than 100 test scenarios, Node management on the Grid project is unfortunately not as capable as it seems.

I have listed the main problems encountered as follows:

• Faulty tests hanging on nodes.
• If too many nodes are connected to a hub, experiencing interruptions.
• If there are too many tests in the queue, it will timeout after a while or cannot be forwarded to the nodes. Severe slowness with too many test runs.

What I see most fundamentally is that the current Grid project is not designed properly for heavy load. Besides, it does not have a stateful structure. So if the hub crashes, everything starts over.

Several projects were developed that solved this. One of the most popular is the Zalenium project developed by Zalando, but the main problem here is that the distributed structure has limits. In addition, if it experiences similar problems in real instances due to its Docker-based operation, the access will be completely lost again

#devops #performance #architecture #selenium #selenium grid