Selenium Grid Philosophy

One Remote Control = One browser = One Environment

The rationale is:

• This simplifies dramatically the remote control reservation/stickiness process
• Easy to get something out the door quickly if we rely on this assumption on the short run
• More than one IE instance for the same remote control does not work
• Remote control is not very stable and need to be restarted quite often. The restart has less impact if only one browser is running at a time.
• You can still scale by running multiple remote control on the same machine
• This way each remote control can offer different environment capabilities on the same box. e.g "IE 7 on Windows" and "Firefox on Windows".

You are the one in control

The same test can run locally on a traditional remote control or remotely on the Selenium grid

• The selenium test can run the same locally with a "classic" selenium setup or talking to the selenium grid => Tests are written as usual using your favorite selenium client driver (ruby, python, java, ...). This makes it easy to troubleshoot failing tests.
• The selenium test itself is in charge on test isolation : reusing the same browser across test, rolling back database to a known state, etc. This is because the person writing the test is the only person who knows what makes sense for a specific web application and which tradeoff he is willing to take between test isis the only one aware

Lessons learned

• Remote Control are not very robust, the need to be restarted regularly
• Running more than one IE on a remote control is not a good idea
• Two _major_ factors for the performance of your selenium test suite are:
  1. Performance of the web server under test
  2. Performance of the network between the remote control and the web site under test