Continuous integration: Functional Testing - Distributed Testing with Selenium and Jenkins

A way to distribute Selenium tests can be use Selenium Grid alone or Jenkins and the Selenium Jenkins plugin. However if more control is required, there's another way with Jenkins. You can configure a Jenkins Master with n-Jenkins Slaves that will execute the Selenium tests like local execution. In other words, Jenkins Slave will execute exactly as developers do in their local environment without any overhead configuration.

So, which are the pros to use this technique instead of Selenium Grid:

• Easy integration: it can be integrated seamlessly into the continuos integration (CI) of our product. 
• Distribution: the same infrastructure can be used to distribute the execution of ANY functional test (jMeter, SoupUI, Selenium...). 
• Dynamic: assignment different browsers capabilities test are more dynamic than with Selenium Grid. With Jenkins Master/Slave, the slave has the labels to conform different tests types that can be executed by any node. For example, the number of executors (instances of browsers) or node labels can be changed directly in Jenkins without restarting the node.
• Reporting: the execution and post execution (reports..) are distributed overall Jenkins nodes. 
• Centralized control: the distribution control is centralized in Jenkins.

Knowing that solution, we can implement this solution with:

• TestNg as core test framework:
• Group functional test in suites (that will be executed directly by the Jenkins jobs).
• Filter test execution by parameters ("@Test(groups='demoUser','pro'"... where we can have different kind of groups, such as different type of users, different environments... ) 
• Definition of executions  "timeouts" (at different levels).
• An easy way to execute the test (from maven, directly with java...)
• Data Driven Test
• Reports
• ...
• Test will be built following the Page Object Pattern. 
• A custom core framework that:
• Centralize configuration management of the test execution (main homepage, main browser type, user, password....).
• Centralize the startup of the browser (select browser by configuration properties)
• Automate the login of the test: every test will only take care of the page to test, navigation through the pages will managed by the core framework
• Execution retry policy (you know that test over IE may fail without reason)
• Manage errors 
• Data Driven Test: data stored in excels organized by 'tables'
• Custom detailed reports
• ...
• Testlink as Test Management.

This is a simplified picture of the platform to automate the execution of Selenium with Jenkins:

You can follow this tutorial to configure Jenkins with Selenium and this other tutorial to configure the Jenkins Slaves.

To sum up,  the main goal of this solution is to use the  Jenkins node "labels" to assign the web browser that will be executed by any node and configure the Jenkins Slaves to execute the Selenium WebDriver without problems (I will write a post about how to configure the Jenkins Slave  properly to execute IE as a service without problems).