kentoh - Fotolia
Docker enables IT organizations to create and manage containers to isolate code without a lot of overhead. Containers offer on-demand, disposable environments that start quickly and can spin up repeatedly, both locally and in the cloud.
While Docker isn't the only container provider, it did popularize the technology. As with VMs, containers share physical computing resources -- CPU, memory, networking and storage -- with multiple guest systems. Unlike VMs, containers rely on the host OS, which enables them to start in seconds.
Teams build container images to package together all the pieces they need for an application to run on that shared OS -- such as preinstalled and preconfigured libraries -- without any additional unused components that can create unnecessary overhead. They are small enough that they move through the software delivery process as a unit.
Each Docker image includes a read-write layer on top for instance data, but the other layers are immutable, meaning they can't change once they've been created.
With containers, the image that you test is the image you deploy to production. Containers can eliminate the common refrain, "but it works on my machine," as the container looks and behaves the same way in the environments for development, testing and production.
Here's how using Docker for testing can make QA easier.
Disposable environments for testing
Because container images are immutable, the instances start up and look identical each time. Containers' quick startup ability enables QA to perform some intrusive testing that can leave the container in an indeterminate state. QA can then kill it and start a fresh copy for the next test. Teams essentially create disposable systems with Docker for testing.
Docker's design for containers focuses on automation, which means developers can use simple commands and API calls to start up multiple containers from different images. Each container is able to discover others and work with them if the code dictates it. For example, a single command can start up a database, application server and web server to run a given program. Seconds after you request it, the entire environment can be up and ready to test.
Everyone on the IT team anywhere in the development, test and deployment pipeline can run an identically configured environment. If the app or feature works on one machine, it will work on them all.
More opportunities to test
The convenient start-stop capability of Docker container environments can enable additional test opportunities. Suites of long-running tests can occur in parallel. Containers also enable stress tests, soak tests and high-availability tests that can take place much earlier than they typically fall in the release lifecycle. And security tests that otherwise take days can play out alongside full regression tests, all while manual testers perform exploratory testing.
Teams can use Docker for testing on the tool side of the equation, as well as with the code. To run test tools in Docker containers, install and configure the tool as an image and spin it up when needed. This functionality can help make institutional knowledge for configuring tools a thing of the past.
With Docker for testing, QA doesn't need to learn how to interact with an extended ecosystem. Simple commands can start up the environment; orchestration tools can enable you to choose from libraries of prebuilt images; and automation tools can start and stop the containers as needed. Testers can, therefore, focus on testing -- not on tool and environment management.
Gene Gotimer will cover this topic in depth in the session "Virtualization and Containers for Automating Web Testing" at STAREAST in Orlando, Fla. The conference runs Apr. 28-May 3, 2019. TechTarget readers can save $200 on registration fees by using promo code SECM. Can't make it to the actual event? Register for the STAREAST Virtual for free. You can stream select presentations live from anywhere.