In this blog we will discuss when/why/how to use the containerization in our day-to-day testing life cycle. We will also discuss about the best practice standardization around the implementation.
Challenges of QA in Agile:
Short time to deliver is a major requirement in Agile Deliveries
QA being an integral part of SDLC, we can’t afford to be in a loose state when it comes to integrity and secure delivery well in time. I used to believe on a term OTIF “On Time In Full”. This means we promise to deliver on time yet in a proper state of consummation. This will happen when we deliver the software with utmost priority yet with best quality. To achieve this goal, the QA practice need to implement new thinking around testing life cycle to achieve better result. Automation is one process where we can achieve quick results. Following activities help to achieve this goal
- A well-built automation test Suite
- Wide range of test cases having functional and non-functional test coverage across multiple channels/browser/OS combinations.
There is a tendency to skip important tests during development due to following reasons
- The testing time slows down the deployment process.
- Too many test cases take a lot of time to execute.
- Too many customizations required to test in different environment like Dev & QA.
Another major challenge on the effectiveness of tests in QA environment is that QA and prod environments are poles apart in terms on configuration, scalability and performance. Designing and executing tests on production like environment brings challenge in terms of infrastructure set up and cost involved in it. The maintenance of the setup also aggravated the challenges to many fold.
Before containerization came into picture, the leading way to isolate, organize applications and their dependencies was to place every application in its own VM. These machines run multiple applications on the same physical hardware, and this process is nothing but Virtualization.
But virtualization had few drawbacks such as
- VMs are bulky in size.
- Running multiple VMs lead to unstable performance.
- Boot up process would usually take a long time
- VM’s would not solve the problems like portability, software updates, or continuous integration and continuous delivery.
These drawbacks led to the emergence of a new technique called Containerization.
What is Containerization?
Containerization is the technique of bringing virtualization to the operating system level. While Virtualization brings abstraction to the hardware, Containerization brings abstraction to the operating system. Do note that Containerization is also a type of Virtualization. Containerization is however more efficient because there is no guest OS here and utilizes a host’s operating system, share relevant libraries & resources as and when needed unlike virtual machines.
Advantages of Containerization over Virtualization:
- Containers on the same OS kernel are lighter and smaller
- Better resource utilization compared to VMs
- Boot-up process is short and takes few seconds
What is Docker?:
Docker is a containerization platform that packages your application and all its dependencies together in the form of a container to ensure that your application works seamlessly.
As you can see in the diagram, every application runs on separate containers and has its own set of dependencies & libraries. This makes sure that each application is independent of other applications. So a developer can build a container having different applications installed on it and give it to the QA team. Then the QA team would only need to run the container to replicate the developer’s environment.
Implementation of Dockers can come to rescue for overcoming the major challenges of quick turnaround for quality delivery with a production like environment. With Docker, you now have a simple way to make testing predictable across multiple platforms by achieving parity between your QA environment and production. This gives you the confidence that when something works on your machine it will also work for your customers.
Docker + Selenium GRID:
Here in this blog we will be using selenium GRID in docker container to achieve parallel execution. We will also use Zalenium to see the live testing of system under test in a CentOS/Linux platform.
In this section, we will discuss how to install/use docker container to use to testing purpose. We will discuss the installation in UNIX/CentOS platform, which is an equivalent to production environment.
Pre-requisite : one server/machine with any of the above OS installed is available handy with admin/root/sudo credentials.
Before proceeding further there is little command difference I need to highlight here. In Unix/Linux “apt-get” will work, but in CentOS “yum” will work. For example:
Sudo apt-get update -y — for Linux/Unix based machines
Sudo yum update -y —- for CentOS based machines
Here in this example we will be using CentOS 7.
Step-1: Uninstall the previous version if exists any.
sudo yum remove docker \
It’s OK if yum reports that none of these packages are installed.
Step-2: Install Docker-CE.
You can install Docker CE in different ways, depending on your needs. Most users set up Docker’s repositories and install from them, for ease of installation and upgrade tasks. This is the recommended approach. In testing and development environments, some users choose to use automated convenience scripts to install Docker. Here we will
Install using the repository
Before you install Docker CE for the first time on a new host machine, you need to set up the Docker repository. Afterward, you can install and update Docker from the repository.
SET UP THE REPOSITORY
Install required packages. yum-utils provides the yum-config-manager utility, and device-mapper-persistent-data and lvm2 are required by the devicemapper storage driver.
$ sudo yum install -y yum-utils \
Use the following command to set up the stable repository.
$ sudo yum-config-manager \
To enable the test channel, run the following command:
$ sudo yum-config-manager –enable docker-ce-test
Step-3: INSTALL DOCKER CE: Install the latest version of Docker CE and container, or go to the next step to install a specific version.
$ sudo yum install docker-ce docker-ce-cli containerd.io
If prompted to accept the GPG key, verify that the fingerprint matches 060A 61C5 1B55 8A7F 742B 77AA C52F EB6B 621E 9F35, and if so, accept it.
To Install a specific version of docker you need to enter the below command.
$ sudo yum install docker-ce-<VERSION_STRING> docker-ce-cli-<VERSION_STRING> containerd.io
Docker is installed but not started. The docker group is created, but no users are added to the group.
$ sudo systemctl start docker
To uninstall the docker:
$ sudo yum remove docker-ce
Step-4: Confirm the docker node.
sudo docker ps -all
Step-5 : To know the active docker node details:
systemctl show –property ActiveState docker
Step-6: Automation Testing using selenium GRID in Docker:
To test the system under test/application in X-browser way, we have to use selenium GRID concepts here. To achieve the same we can do in 2 ways.
- Running GRID in Docker directly:
For creating Hub:
sudo docker run -d -p 4444:4444 –name selenium-hub selenium/hub
For Creating Node:
sudo docker run -d –link selenium-hub:hub selenium/node-chrome
sudo docker run -d –link selenium-hub:hub selenium/node-firefox
Now point your test automation to the above hub and execute the test cases.
- Running Zalenium for GRID:
Zalenium is a mixture of Zalendo and Selenium for a stable GRID with a main purpose to allow anyone to have a disposable and flexible Selenium Grid infrastructure.
Step-1: Install Zalenium for showing parallel test execution and recording
sudo docker pull elgalu/selenium
sudo docker pull dosel/zalenium
Step-2: To start the selenium HUB:
sudo docker run –rm -ti –name zalenium -p 4444:4444 -p 5555:5555 \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /tmp/videos:/home/seluser/videos \
–privileged dosel/zalenium start.
Now the Selenium GRID with hub/node config is ready to use.
Step-3: Execute Automation test cases:
Now point the selenium webdriver to the above machine port 4444 to access the grid and to execute automated testcases.
Clean up after testing:
Step-6: Get all the container details:
sudo docker container ls -a
Step-7: To stop all running containers:
Take the container id from above step and put that in below command to stop them. We have to do it for each container.
sudo docker stop <container id>
Step-8: To remove the containers:
To remove the stopped container from the system we have to prune them.
sudo docker container prune
Docker not only helps us in setting up the selenium grid – but also simplifies managing test dependencies. Here are some of the problems we solved with this approach:
- We can easily share our tests and test environment between each other with minimal or zero configuration that needs to be done before running tests.
- We don’t have to worry about compatibility issues between various selenium and browser drivers versions. It is very easy to change the versions and test them out. Previously, it was very time consuming to install browsers, browser drivers and corresponding selenium web driver and make sure all of them work together.
- You can set up a cluster of various nodes for a specific browser and run your tests against different versions of browsers to know which ones your tested application covers. Previously, it was nearly impossible to maintain multiple browser versions, browser drivers and selenium web driver gems on one machine. It was compatibility/dependency hell.
- Very easy setup in CI environments