Author: harvar

Docker Integration with Selenium Grid

Posted on by harvar

In the present QA world, scalability is the main focus area for many companies. Due to the vast implementation of the Agile model, it is inevitable to go through quick feature changes which result in reduced testing time. To resolve this, automation testing is now taking on the world, and we all know that Selenium is leading in this automation implementation. 

As the testing time has been reduced for multiple releases and frequent feature change, QA teams have decided to find ways on reducing execution time of automation and provide parallel execution for cross browser support. That’s where the use of Selenium Grid and Docker comes into the picture.

Now to perform cross browser testing or running a huge automation suite in parallel to reduce the overall execution time, we need to make sure that execution shouldn’t occur in sequence. We should rather execute them in parallel. The main reason behind it is time. Let’s take an example – if the test suite execution time is 40 minutes, then if we execute in sequence across 3 different browsers, then the total time for entire execution would be 120 minutes. However, if parallel execution is supported with Docker containers, we can save 80 minutes in one test run!

As we have got a basic idea about the importance of Docker and Selenium Grid in automation testing, let’s try to implement the same in the existing test suite.

Overview

Let’s first get an overview of Docker and Selenium Grid. 

Docker Overview

Docker is an open platform for developing, shipping and running applications. Docker enables you to separate your applications from your infrastructure so you can deliver software quickly. With Docker, you can manage your infrastructure in the same way you manage your applications. By taking advantage of Docker’s methodologies for shipping, testing and deploying code quickly, you can significantly reduce the delay between writing code and running it in production.

To know more about Docker, please refer to https://docs.docker.com/.

Selenium Grid Overview

Want to run tests in parallel across multiple machines? Then Grid is for you.

Selenium Grid allows the execution of WebDriver scripts on remote machines by routing commands sent by the client to remote browser instances.

Grid aims to:

  • Provide an easy way to run tests in parallel on multiple machines
  • Allow testing on different browser versions
  • Enable cross platform testing

Interested? Go through the following sections to understand how Grid works, and how to set up your own.

How to Integrate Docker with Selenium Grid

Let’s go through the steps to set up Docker with Selenium Grid. The setup shown below has been done on a Windows machine, but the steps in macOS are also quite similar. 

Step 1: Install Docker

Download Docker in Windows: https://docs.docker.com/docker-for-windows/install/

Docker Desktop does not start automatically after installation. To start Docker Desktop, search for Docker, and select Docker Desktop in the search results.
When the whale icon in the status bar stays steady, Docker Desktop is up-and-running, and is accessible from any terminal window.

If the whale icon is hidden in the Notifications area, click the up arrow on the taskbar to show it. To learn more, see Docker Settings. When the initialization is complete, Docker Desktop launches the onboarding tutorial. The tutorial includes a simple exercise to build an example Docker image, run it as a container, push and save the image to Docker Hub.

Download Docker Desktop for Mac from link here (Mac with intel chip):

Step 2: Verify Installation of Docker

Go to CMD and type below command:”docker –version”==>

C:\Users\sshukla>docker –version

O/P: Docker version 19.03.8, build afacb8b

Step 3: Pull Docker Images

Go to below Docker hub link and search for images to pull into your local machine:

https://hub.docker.com/search?q=&type=image

Pull all the below three images using Docker cmd:

 

  1. Pull Selenium-hub image using command ~ docker pull selenium/hub
  2. Pull FireFox Debug image using command ~ docker pull selenium/node-firefox-debug
  3. Pull Chrome Debug image using below command ~ docker pull selenium/node-chrome-debug

Step 4: Verify Images

Check that the images that have been pulled in step 4 are present by using command: docker images

C:\Users\sshukla>docker images

OUTPUT:

REPOSITORY      TAG         IMAGE ID        CREATED         SIZE
selenium/standalone-chrome latest          3adc798b45d8    9 months ago    910MB
selenium/node-firefox-debug   latest          86e57cf1c72c    9 months ago    871MB
selenium/node-chrome-debug latest          845cb7d30dec    9 months ago    941MB
selenium/hub              latest          f476afa5404c    9 months ago    263MB
ubuntu                    latest          ccc6e87d482b    13 months ago   64.2MB
ubuntu                    <none>          775349758637    16 months ago   64.2MB
hello-world    latest        fce289e99eb9    2 years ago     1.84kB

Step 5: Running Docker Container

Run below three commands in sequence:

  1. docker run -d -p 4446:4444 –name selenium-hub -P selenium/hub
  2. docker run -d -P –link selenium-hub:hub selenium/node-chrome-debug
  3. docker run -d -P –link selenium-hub:hub selenium/node-firefox-debug

For ease of execution, expect below results while running above three commands:

  1. Let’s execute the first command as mentioned above in the command line:
docker run -d -p 4446:4444 –name selenium-hub -P selenium/hub

Expected output for the executed command would be similar to below:

O/P:3e4bc48fa50f45526e18f635e085caeb3ad548671e8cbcbd5977931a58075193

To confirm that above command executed and container created, use below:

==>C:\Users\sshukla>docker ps

OUTPUT:

CONTAINER ID   IMAGE   COMMAND     CREATED   STATUS   PORTS     NAMES
3e4bc48fa50f   selenium/hub “/opt/bin/entry_poin…”   14 seconds ago Up 11 seconds   0.0.0.0:4446->4444/tcp   selenium-hub

2. Let’s run the next command from the command line:

docker run -d -P –link selenium-hub:hub selenium/node-chrome-debug

When we enter the above command in the cmd, we expect a reply as shown below:

O/P: bb839e51b74373c0a39477134658e93e42256ac15340625cb92fb95255538e70

To confirm that above command executed and container created, use below:

==> C:\Users\sshukla>docker ps

OUTPUT:

CONTAINER ID  IMAGE  COMMAND     CREATED  STATUS  PORTS     NAMES
bb839e51b743    selenium/node-chrome-debug   “/opt/bin/entry_poin…”   8 seconds ago   Up 6 seconds    0.0.0.0:32768->5900/tcp   bold_booth
3e4bc48fa50f    selenium/hub             “/opt/bin/entry_poin…”   2 minutes ago   Up 2 minutes    0.0.0.0:4446->4444/tcp selenium-hub

3. Now let’s move forward and execute the last command:

docker run -d -P –link selenium-hub:hub selenium/node-firefox-debug

Expected output for the above command would be as below:

O/P: e6997998907ae917d392ee3559501d3e2324c5622a33b2be1d75d3f7dcebfcd4

To confirm that above command executed and container created, use below:

==> C:\Users\sshukla>docker ps

OUTPUT:

CONTAINER ID  IMAGE   COMMAND  CREATED   STATUS    PORTS   NAMES
e6997998907a    selenium/node-firefox-debug   “/opt/bin/entry_poin…”   8 seconds ago   Up 8 seconds    0.0.0.0:32769->5900/tcp   vigorous_galois
bb839e51b743    selenium/node-chrome-debug “/opt/bin/entry_poin…”   2 minutes ago   Up 2 minutes    0.0.0.0:32768->5900/tcp   bold_booth
3e4bc48fa50f    selenium/hub              “/opt/bin/entry_poin…”   4 minutes ago   Up 4 minutes    0.0.0.0:4446->4444/tcp selenium-hub

Step 6: Creating Sample Test

Create two tests – one for Chrome and the other for Firefox as shown below. The reason we are creating two tests is because our main intention is to show a scenario where we can run the same test script for both Chrome and Firefox in parallel on two containers using Grid and Docker.

@Test
    public void chrome() throws MalformedURLException, InterruptedException {
   ChromeOptions dcc = new ChromeOptions();
   dcc.setCapability(“browserName”, “chrome”);
   dcc.setCapability(“OS”, “Windows”);
   WebDriver driver = new RemoteWebDriver(new URL(“https://localhost:4446/wd/hub”),dcc);// pass the url of selenium hub
   driver.get(“https://www.google.com”);
   Thread.sleep(5000);
   driver.quit();  
}
@Test

 public void firefox() throws MalformedURLException, InterruptedException {
   FirefoxOptions dcc = new FirefoxOptions();
   dcc.setCapability(“browserName”, “firefox”);
   dcc.setCapability(“OS”, “Windows”);
   WebDriver driver = new RemoteWebDriver(new URL(“https://localhost:4446/wd/hub”),dcc);// pass the url of selenium hub
   driver.get(“https://www.google.com”);
   Thread.sleep(5000);
   driver.quit();   
}

Step 07: TestNG.xml for Parallel Test

Create a testNG.xml file with parallel tests and thread count=2 as we are trying to execute the test in two browsers in parallel.

<?xml version=“1.0” encoding=“UTF-8”?>
<!DOCTYPE suite SYSTEM “http://testng.org/testng-1.0.dtd”>
<suite name=“Automation Test Suite “ parallel=“tests” thread-count=“2”>   
    <test name=“Automation Test CasesChrome”>
   <classes>
 <class name=“com.task.automation.testtwo.testone”/>
   </classes>
   </test>
   <test name=“Automation Test Casesfirefox”>
   <classes>
 <class name=“com.task.automation.testtwo.testfirefox”/>
   </classes>
   </test>
</suite>

Here are the commands to execute the ‘testNG.xml’ file from the command line:

cd F:\Selenium\SampleTestNG
java -cp F:\Selenium\SampleTestNG\lib\*;F:\Selenium\SampleTestNG\bin org.testng.TestNG testng.xml

After executing the above command, it should execute the tests that we have specified in the testNG.xml file. We will be able to see the test running through two different browsers that we have created using Docker containers.

Benefits of Using Docker with Selenium Grid

Docker helps to achieve scalability and easy deployment on multiple servers. Selenium Grid can be implemented using Docker containers, and it can be done in a single machine, or the infrastructure and parallel execution count can be increased easily. One of the most important benefits of Docker is its capacity to scale. It’s particularly helpful because running a Selenium grid on virtual machines or even separate machines takes up a lot of unnecessary computing overhead.

Docker images are based on shared system resources, so they need fewer resources than a virtual machine. Several nodes can be deployed in a single instance. 

If we need to validate our tests on different browsers like Chrome, Firefox and Safari, then creating multiple docker containers and executing them in parallel is the most convenient and feasible way of execution.

Conclusion

In the present world, supporting multiple browsers or multiple mobile devices is very important for a product. But to test with multiple browsers or devices is not cost effective and very time consuming. Docker container integration for Selenium will help overcome both issues of cost and time; it is practically cost-free and with the power of parallel execution, we are able to execute our test scripts on all the required browsers with time use for execution in one browser.

For automation or SDET job roles, it is quite important to learn about the test execution environment setup with Docker containers. The more we are moving towards DevOps, it seems for QA to learn Docker integration is inevitable. If you are looking for jobs in SDET or Automation Testing roles then do check Talent500. You can find multiple opportunities in the jobs link here.

 

 

CI/CD integration with automation testing

Posted on by harvar

CI (Continuous Integration) & CD (Continuous Delivery) has been gaining a lot of attention and is the most hyped topic in the technology world. It helps the companies to ship their products quickly and efficiently. Initially it was difficult to implement CI/CD in projects but now with a lot of tools available in the market, it is becoming quite easy to make your project implement continuous integration with ease and speed.

Among all the different types of tools available in the market, the most used one is Jenkins. In fact, as per Slintel data, Jenkins has a market share of 47.69%. But we can’t avoid the fact that some more tools like Bitbucket, CircleCI, TeamCity are also claiming their existence gradually.

The point to gain attention here is the use of Selenium tests in Jenkins. With the feasibility of CI/CD, a team would want the regression suite designed with Selenium to execute each time there is change in software code. To achieve the same, we need to integrate our automation suite into CI/CD tools to schedule the run.

Why we need CI/CD integration with automation testing

Due to the Agile process and frequent changes in features, the number of builds provided by developers has been exponentially increased. Continuous integration involves committing code changes to master regularly, triggering a build if applicable and testing the software each time. 

To really get the benefits of CI, your team members should aim to commit changes at least daily. However, even on a small team, doing this level of CI/CD automation testing manually would involve a huge amount of repetitive work tasks. This is where the automated testing comes in.

If you’re manually running 10 builds a day at 10 minutes each, that’s 100 minutes wasted in deployment! Furthermore, testing the same again would be tedious, and due to multiple release cycles the quality would be compromised. 

The above mentioned approach not only puts the developers behind the schedule, but it’s also going to impact their attempts to push changes to production due to delay in testing and at the end it will reduce the company’s bottom line with new products and features. So to resolve the same, we need to come up with processes which can help us to automate the deployment and testing process on the go, just like Jenkins pipeline does in the release cycle.

One of the major roles of CI/CD integration is when the team is working in multiple time zones. Working in different time zones increases the duration of testing without CI/CD. If the developer team pushes the code in PST, and then if the testing team works from IST, it will take the QA another 12 hours to start testing. So instead of manually testing or triggering the automation suite, we can use the CI/CD pipeline to trigger our automation suite after the code is being pushed by developers.

Steps to integrate AutomationSuite with Jenkins

In this section, we will integrate the Automation Suite with Jenkins job, so that whenever required we can trigger our test suites from the pipeline or even schedule the same. Remember that in the below demo we are using testNG.xml suite and the framework is designed with Maven pom.xml.

Prerequisite for running :
         – Automation suite in testNG.xml
         – Jenkins server access with valid credentials

 Step 1

Integrate testNG.xml suite with pom.xml. To do that, we have to pass the path of testNG.xml suite inside the suiteXmlFiles tag. We need to remember that the path which has been provided here is the path of testNG.xml suite used in our project, so you need to use the path as per the suite located on your setup. Instead of Regression we can also pass the path of Smoke, Sanity, BVT or Confidence suite.

<suiteXmlFile> tag of pom.xml:

<configuration>
<suiteXmlFiles>
<suiteXmlFile>resources\testNG_xml\RegressionSuite.xml</suiteXmlFile>

        </suiteXmlFiles>
</configuration>

 To get the entire pom.xml with dependencies required in Selenium Automation Framework, refer the link below:

Click link here for pom.XML

Step 2

Go to your Automation project path and open the command prompt. As shown below, project name is “Task” and we have opened cmd @project location:

Step 3

Enter maven goal for test as: “mvn clean test” in the command prompt and hit ENTER. This will execute all the test scripts present in our suite and provide the execution status. This step is very important before starting the integration with Jenkins.

If it fails while running in the command prompt then we need to make sure to fix all the issues before moving it to the Jenkins server.

Step 4

Go to Jenkins, click on New Item as shown in below screenshot. This new item will help us to create a new Jenkins job where we can integrate the automation suite which has all the test scripts for the regression suite.

Step 5

Provide the name for the job, in the below screenshot we have provided the project name as “UiAutomationG11” and select “Maven Project” click on OK button. We need to release that as our automation framework is in Maven so we are selecting Maven project, if you are using Gradle then you have to select accordingly.

Note: Always provide a meaningful name to the project with proper naming convention.

Step 6

Go to Build Select “Invoke top-level Maven targets”, then enter the Goals as “clean test”, and put the pom.xml path of your project in the “POM” section as shown below. Now click on the “Save” button which is in the left bottom section.

Remember that as we are using it for demo so our pom.xml is in our local machine and we are providing path of the project in the POM section, but if you are trying to implement at project level then you need to integrate your GitHub repo link in Jenkins so the code will be pulled from repo directly.

Step 7

To run the suite, click on the Build Now button as shown below, once you click it will trigger the automation suite and test scripts will get executed. After the execution will get completed we can see the status of the job run, and if it fails then the console output can be used to get the error logs for further fixes.

Benefits

The most important benefit that the team will achieve is attaining the quality with the utmost pace. Below are some of the most important benefits of continuous integration with Automation Testing:

Faster release cycle

Pacing up the build and testing cycle will allow the team to get new features into production quicker. It also helps to reduce the testing execution exponentially by triggering from the pipeline. Pipeline helps the organization to accelerate the release rate.


High quality

Any software development process that includes continuous testing is on its way toward establishing a critical feedback loop to go fast and build effective software by making the automated suite part of the pipeline. As we run our suite after every change done by the developer team, it always provides a quality check of each and every code pushed to the code base. Most importantly, the pipeline with continuous testing builds quality into the CI/CD pipeline and reduces risk and waste in the software development lifecycle.


Simplify rollbacks

Integration of automation with the pipeline helps to put a check on code changes. If the tests fail, we can easily rollback the changes to working state. In most of the cases, we basically rollback to the last successful build.


Conclusion

Automated testing plays a key role in any CI/CD pipeline. Although creating automated test suites will take some time & money, making it part of the pipeline to run a check on every deployment soon pays for itself.
 Whenever developers make some changes to the code base, pipeline integration helps to run the regression and make sure that new changes haven’t impacted the existing features. So apart from validation, the automation in the pipeline provides confidence to the development team.

In the current market scenario, if you are trying to move to a product company or SDET role, then knowledge in CI/CD is a very important attribute. If you want to explore opportunities in a similar field, do check Talent500

Talent500 helps to hire, build & manage globally distributed workforces, and has a large number of career-defining opportunities for tech professionals such as you.

Talent500 helps the world’s fastest growing businesses build their global workforce.

We help companies hire, build and manage global teams. We are trusted by industry leaders across the globe – from Fortune 500s and larger enterprises, to some of the world’s fastest-growing startups. We are backed by Accel Partners & ANSR, a global leader and enterprise transformation platform.

Facebook Linkedin Instagram

Home

Discover Jobs

Enterprise blog

Professionals blog

About us

Terms of use

Privacy policy

Contact us