The SQA2 Blog: General
One of our clients was in the midst of creating a fairly extensive website, which needed to be tested on a relatively narrow but very specific list of browsers and browser versions. In the past we would have had two main options for getting these tests done. We could have had our client pay for a service that allows you to run tests in hundreds of browsers and browser versions, knowing that this option can get quite expensive. Or we could have done the testing locally on our own server, which would have required a great deal of set-up time as we spun up a separate VM (virtual machine) for each version of each browser.
Luckily, we were able to leverage a much better option: Docker. Using Docker enabled us to quickly and easily create self-contained testing environments for each of the needed browsers, run all of the tests in parallel and get the job done.
What exactly is Docker?
Docker is a tool that enables you to create and share containerized environments in which an application can run.
In Docker the “containers” are built based on “images,” which are essentially blueprints of the desired environment and everything that needs to be installed in that environment (such as operating system, programming language, libraries, code, etc.) to allow that application to run. Once an image is created it can be used to make as many containers as desired. Each container will be a self-contained eco-system containing everything from the operating system to the code.
What are the overall advantages of Docker?
Although containers have been available in Linux for quite some time, Docker’s popularity stems from its user interface, which makes using containers so much easier. The many advantages of using Docker containers include:
- Consistency – Because all of the variables are defined in the image, and each container is a separate and complete eco-system, whatever is being run inside the container is not affected by whatever is being run outside the container. Once you start a container in Docker, all that container needs from the system is CPU and memory. The container’s operating system, libraries, etc. are all as defined by the image.
Docker lets you control and keep consistent both the code or program that you’re building and the environment in which it runs.
- Agility – Docker eliminates the need to spin up multiple VMs. Once a blueprint (i.e. image) for an environment is created, using this blueprint to create a new container is a very simple process. Compared to configuring a new VM, using an existing image to create a new container is extremely fast and easy. It’s like the difference between going through a list of 50 steps to manually configure a desired environment and needing just two to five steps to get things up and running.
- Collaboration – You get a lot of value from building an image once, putting it in a source-controlled location that’s accessible to the entire team and then letting everyone reuse it as many times as needed.
- Speed – Best practices call for putting just the bare minimum needed for a particular core process in each container. By their nature containers are meant to be small. Processes work quickly in containers because all of the bloat that typically comes with an environment has been removed.
- Isolation – The processes that are running within a container are isolated from everything else that is running on the same computer. This allows you to create feature-specific environments in which you can simultaneously but separately test multiple features, processes or updates, without interacting with anything else that is being run on that machine.
How does Docker impact QA testing?
From the standpoint of what needs to be tested, Docker does not impact QA at all. If the development team has integrated Docker into their development processes, this Docker infrastructure does not impact the tests that QA needs to run. The same things need to be tested as before.
What is Docker’s biggest benefit for software development QA?
Confidence. From the QA standpoint, one of Docker’s biggest benefits comes from the consistency of the containers. Simply put, Dockers eliminates configuration issues and essentially guarantees that what you test is what you deploy.
It used to be that when a developer wanted to deploy their program to a specific environment, there were lots of issues around configuration changes and manually doing updates, managing scripts, etc. Now the developer simply creates an image of the desired environment. Both the developer and QA can then use that image to spin up containers, eliminating the time-consuming manual configuration process, and the errors that used to happen when QA attempted to duplicate dev’s desired environment.
Once an image is created, you can be assured that every container created from that image will be identical, and how the code in that container runs will not be affected by the machine on which the container (or an identical container) is running. It won’t even matter if, for example, the engineer is running on Linux and QA is running on Windows. The program inside those containers will run the same way across the board, because the containers will include their own operating systems and complete environments.
This consistency gives you confidence that if a specific container full of code works during testing, that container will perform the exact same way when placed in production.
A good analogy here is that of a chain of restaurants versus a food truck. If a chef is making food in a food truck (i.e. a self-contained eco-system), no matter where that truck is parked her working environment will not change. But if you’re moving that chef from restaurant to restaurant, she’ll have to adjust to the fact that the kitchen will be at least slightly different in each location. A process that worked in restaurant #1 might run into problems at restaurant #2.
How else does Docker benefit software development QA?
By eliminating the need to manually configure environments on VMs, using Docker containers not only gives us confidence that what we’re testing is what will be deployed, it also lets us:
- Deploy and scale test environments much more quickly, including testing applications or websites in different browsers or different versions of software (most of which are readily available for Docker).
- Take advantage of feature-specific environments, so that each individual change can be tested in isolation before testing things together.
- Create environments for running our automations, including spinning up Docker containers to hold the mock data.
The industry is heading towards Docker, and for good reason. Docker makes resource management easier. It speeds up the development cycle. And it offers security that things will work the same in production as they did during the development and QA processes. It’s no wonder QA is embracing Docker.