Shift Left? Shift Right? Continuous Improvement Depends on Both

As you dig into DevOps methodology, you’re likely to encounter the term “shift left” and the slightly less common “shift right.” What exactly are we shifting here?

The two terms are sides of the same coin. They refer to when you will test your application or piece of technology – is it during development or once your solution has already entered production? Of course, for true DevOps success, the answer is both! Continuous improvement involves testing at all phases of the application lifecycle.

Let’s take a closer look at the ideology behind “shift left” and its counterpart as well as how they affect the development cycle (which can also be applied beyond app development itself and used when designing and deploying most IT systems).
 

Testing ideas vs. testing production

Shifting left can be thought of as testing ideas. You must anticipate the end-user experience and brainstorm potential design flaws before they reach production. Shifting left involves design thinking and a strong test / QA team who can help the development and/or architecture team test an application throughout the plan, branch, code, merge, and build phases.

With a shift-left mindset, dev or architect teams can often catch bugs or critical conceptual errors early in the process, meaning they are easier (and often less expensive) to remedy and never have a negative impact on the client or end-user.

QA in turn becomes part of the process for the entire development and operations team, helping you achieve forecasted project timelines and reach the market faster – one of the main goals of DevOps.

Testing under shift left means testing your ideas themselves, all the way down to the original whiteboarding sessions. It means securing feedback from the client or end user on the new feature ideas. It often means using behavior-driven development techniques. Security and performance are tested as the feature or product is developed, not after it reaches QA or beta.

On the flip side of the coin, shifting right can be thought of as testing the live environment. There will always be factors you can’t anticipate both from the application or solution itself as well as external influences like the user, integrated systems, network or Internet at large, and so forth. Testing must continue once you are in production to ensure controlled testing of functionality, performance, and user experience.

Common methods of shift right testing include using live production traffic funneled via API to a test instance to mimic real-life conditions for a new release, as well as automated testing tools, A/B testing, canary releases in which the new features are pushed out to subsets of the user pool first, and testing in production itself. When it comes to the latter, the mantra “fail small and fast” is common. Small incremental releases with close monitoring help mitigate the damage and quickly report back to development.
 

Don’t Shift – Just Stick with Holistic Testing

Shift left helps you deliver an IT solution or product that is as ready as it can be for production in as little of time as possible. Shift right helps you refine and improve the customer experience as it plays out in the real world.

By implementing both shifts, you discover that agility comes at all stages of the pipeline. That is the main goal behind DevOps after all – integration of all aspects of your software or IT service delivery. Therefore you should not only be testing at the plan, branch, code, merge, and build stages; but also within the release, deploy, operate, and monitor stages. In the old waterfall model of IT development and deployment, testing would be concentrated at mostly one stage lying between development and operations, post-concept and development and pre-deployment.

Shift left and shift right are useful concepts in how they help us recognize the different loops of DevOps and how we should widen our testing scope to encompass both the left (Dev) and right (Ops) sides. But testing should not only shift left or shift right but rather be practiced continuously. This holistic testing is essential for continuous improvement in your product and service delivery.