This blog was originally posted on July 18, 2016 and was updated with revised content on August 21, 2020.
The concept of "shift left" is a key component to successful DevOps, continuous integration, and continuous deployment initiatives. To "shift left" simply means to conduct more testing earlier in the value stream (i.e. move it to the "left" on a left-to-right stream representing the continuous journey from planning, development, to deployment and beyond. The goal of shifting left is to deliver applications faster with less effort/cost).
The Relationship Between Shift Left Testing and DevOps Automation
What is the point of doing a leftward shift? There are several good reasons for organizations to enable earlier testing in the value stream:
- Defects become increasingly expensive to fix the later they are discovered in the application lifecycle. The well-known chart from IBM Systems Sciences Institute on the relative costs of such bugs demonstrated that a flaw discovered during testing costs 15 times as much as one found during design, while one revealed during maintenance costs a staggering 100 times as much.
Source. - It's easy for teams to become bogged down by long backend test cycles. Regardless of how quickly they might move through the project's sprints, they could still end up not being able to ship what they had worked on, and instead needing to go through a big "end game" push. This is often both a technical and cultural issue, and one that can cause big delays as well as budget overruns.
- DevOps success is contingent on the ability to move significant parts of the software lifecycle leftward. Traditional application development often divided up responsibilities between dev (responsible for coding, testing, etc.), QA (responsible for pre-deployment testing), and ops (deployment and operations), but DevOps seeks to break these silos and enable continuous testing and deployment by cross-functional teams.
"[T]he more effort that is shifted left or earlier in the process, the better," explained Derek Weeks of Sonatype. "When you can make design and architecture decisions early, when you can select the right component from the beginning, when you can identify problems early, when you can fix bugs and vulnerabilities, early, etc., you can improve your software delivery capability, you can improve the reliability and trust of your applications, and you can reduce your development and maintenance costs."
The longer it takes to discover software flaws and defects, the more expensive it is to address them.
Keys for Shifting to the Left
If shifting more tasks to the left is required, let's look at some key building blocks that will give organizations a practical way to start shifting left.
Automation
Automation is a key component to shifting left because it reduces the effort and time required to perform testing, configuration, and deployment activities. Continuous integration tools like Jenkins allow organizations to begin automating the overall build and test process — kicking off automated builds and tests when new code is checked into a source repository. Test automation tools and platforms allow creating test automation flows for unit, integration, performance, regression, and acceptance testing. Infrastructure-as-code tools like Terraform, CloudFormation, and ATM templates allow created automated provisioning workflows to support such dynamic testing. Platforms like Quali's CloudShell make it possible to seamlessly connect CI tools and offer users on-demand test environments that eliminate much of the headache in continuous testing.
"Automation has to be an integral part of the leftward shift."
Containers
Container technology offers a unique way to shift development and test activities to the left. Containers allow applications and their dependencies to be bundled in a container that can be easily created or destroyed on the fly without any additional automation, making it easy to create and store simple predefined application environments for development and low-complexity testing. Because containers make it easier to create re-usable application environments without a ton of automation harnessing, they allow dev and test engineers to perform more integration and advanced test activities earlier in the dev/test cycle.
Test Environment as a Service
Test Environment as a Service fills a gap that is not addressed by simple provisioning workflows or containers in terms of shifting left. For many organizations, the complexity of the applications and infrastructure is growing at a rate that makes spinning up realistic or "production-like" environments early in the dev and test cycles extremely difficult. Shifting left demands creating realistic application and infrastructure environments as early in the dev/test process as possible, but multi cloud requirements, data management dependencies on legacy infrastructure, new network architectures and technologies, and application support technologies like service virtualization all make modeling, maintaining, and managing these kinds of realistic dev and test environments very difficult.
A sandbox environment has similar portability and repeatability as a container, but it contains for the infrastructure rather than the application. A tool such as CloudShell used for Test Environment as a Service gives developers and testers the ability to model complex application and infrastructure environments which can then be shared with other users and deployed on the fly. Plug-ins to DevOps ecosystems tools such as CI/CD products, artifact management tools, source control repositories, and secret management eliminate the need to glue tools together. For example, Jenkins and Azure DevOps can trigger an entire test environment for testing a complex cloud application in one call, rather than having to tie together complex scripts. Ultimately, the sandbox environment allows teams to model multi and hybrid cloud infrastructures to ensure that applications work as well as possible and as early possible in the dev/test process.
The takeaway: Shift-left testing is an important part of adopting agile practices. The concept entails earlier and more frequent tests, at the left side of a left-to-right continuum representing the software development lifecycle. Using CI/CD tools in conjunction with Test Environment as a Service can make shifting left a reality. They also make it easier to get to the next level — shifting right.
Want to learn more? Watch this QualiFYI episode on continuous testing, featuring Broadcom.
