Shift Left vs. Shift Right: 2 Testing Strategies Explained

In this day and age, any engineering leader worth their salt understands the importance of software testing. Simply knowing that testing is important is no longer enough, though; it's vital to have a deeper knowledge of it. This post helps clarify the "shift left vs. shift right" debate that exists in software testing.

‍
Without spoiling anything—you'll see a complete definition soon—we can say that shift left and shift right are both important testing strategies that are part of the overall agile/DevOps landscape. And, despite being polar opposites, they don't necessarily always compete with each other—even if that sounds like a contradiction.

‍
We'll open the post by defining both strategies, starting with shift left. Then, we'll explain how the two approaches compare, when one is more advantageous than the other, and why using both is not only possible but generally desirable. Let's begin!

What Does Shift Left Mean?

The term "shift left" might at first sound somewhat weird. What is it exactly that you're shifting left, and to the left of what?
Well, imagine the software development process as a line. The more you move to the left of that line, the closer to the start of the software development process you're going. Conversely, the more you go to the right, the closer you are to the application running in a production environment.
So, "shifting left" means moving a certain activity to the start of the SDLC (software development life cycle). "Shift-left testing," then, is the practice of testing as early in the software development process as possible.

‍
Why do people adopt shift left? Well, agile methodologies emphasize shorter cycles of feedback. Early and frequent feedback allows software teams to diagnose and fix errors quicker before they cause damage. Additionally, testing at the earliest stages of development enables teams to find problems with their testing process itself—such as flaky tests or lack of expertise with test automation tools—early on.

What Does Shift Right Mean?

Now that you know what shifting left means, it's easy to deduct the meaning of shifting right. It means performing activities—e.g., testing—closer to production. Shift-right testing, specifically, means performing testing and other quality monitoring activities—such as gathering metrics and monitoring security and performance—when the software is in production.

‍
Since we sang the praises of shift-left testing during the previous section, you might be expecting us to trash shift right testing in this section.
That's not the case.

‍
Shift-right testing is a legitimate and valuable approach. The production environment will always have conditions that are impossible to mimic in a staging or QA environment. Because of that, an application might face issues as soon as it goes live that the team couldn't detect during pre-production testing.

‍
Sometimes, it's important to verify how the live application handles unforeseen scenarios in the real world. That's useful not only to test if the application can handle errors graciously but also as a sanity check for your incident response tools and processes. A popular approach for doing this kind of testing is chaos engineering or chaos testing, which consists of simulating problems with a live application, and that's a great example of how shift-right testing can be valuable.

‍
Synthetic monitoring is another valuable type of shift-right testing, which consists of using automation tools to simulate users interacting with high-risk paths of the application and then closely monitoring its performance.

‍
A/B testing is another form of testing we can consider shift left. With A/B testing, teams serve different versions of their application to two groups. Then, they collect metrics to compare the users' responses to the various versions, obtaining insights that can lead to reliable business decisions.

What's an Example of Shift Left?

Picture this: you're writing an e-commerce application. Let's say it's a React Native application backed by a Node.js RESTful API. So, what would shift-left testing look for such an app? Shifting left means starting the test activities as early as you can. The logical conclusion would be testing even before a single line of production code is written. This calls for using a methodology such as BDD (behavior-driven development), TDD (test-driven development), or a combination of both.

‍
Using BDD, development would start by writing high-level scenarios in plain English following a syntax called Gherkin. For example, the following is a scenario that describes the behavior of a shopping cart:

Feature: Buyer adds products to their shopping cart

Scenario: Shopping cart is empty    

Given the shopping cart is empty    

When the buyer adds an item to it    

Then the shopping cart should have one item

The next action would be converting the outline above to a skeleton of an automated test. A software engineer would then write the actual test cases, which then fail because there's no production code written just yet. The next step would then have an engineer implement the production code to make the test cases pass.

‍
The exact approach used to write the production code might vary, but a great idea is to use TDD. In this approach, engineers create a failing unit test. Then, they make the test pass by writing the minimum amount of production code. Finally, they refactor the code to eliminate code duplication and other issues.

‍
If you think that TDD sounds a lot like BDD, that's not a coincidence. BDD operates at a higher level, and it concerns itself with features from the point of view of the end user. TDD, on the other hand, resides at a lower level; TDD tests are more concerned with implementation details and serve as a sanity check for developers.

‍
Though that's not the primary reason for using these approaches, the usage of both BDD and TDD results in regression test suites that are run during the CI/CD pipeline and can be used as safety nets, so engineers are confident when making changes to the code.

What's an Example of Shift Right?

Let's see some examples of shift-right testing, again using the example of an e-commerce application:

• Canary testing. The team could use this approach to deliver an improvement to the search functionality to only a small subset of the users and then slowly roll it out to the whole user base if the improvement succeeds.
• Synthetic monitoring. In the context of e-commerce, the journey from searching, selecting, and adding a product to the cart is critical. The development team could employ synthetic monitoring to verify whether such flows work correctly in real-world conditions.
• A/B testing. The development team could use A/B testing to test how a change to the shopping cart functionality is received by users, and use the insights gathered to decide whether to adopt the change and roll it out to the whole user base.
• Chaos testing. An e-commerce application should ideally never have any downtime since that means a loss of revenue. So, the app should be robust and able to graciously recover from most errors and unforeseen situations. Chaos testing is an excellent approach for checking that. In our example, we could feed the application invalid data, simulate loss of connection with the database, and make invalid requests to the underlying API.

Shift Left vs Shift Right: How Do They Compare?

Shift-left and shift-right testing are both valuable approaches to software testing. Ideally, you can and should be able to use both, since each addresses different kinds of problems. However, there are situations in which one of the approaches makes more sense than the other.

‍
For instance, healthcare and finance are highly regulated industries in which issues in production can have dramatic consequences. In such a scenario, developers must have an incredibly high level of confidence in the correctitude of the code shipped to production. Approaches that accelerate the deployment to production, relying on monitoring and rapid rollbacks, don't work here. So, shifting left is the more appropriate approach.

‍
On the other hand, there are applications in which production issues are less dramatic, especially if they affect only a portion of the user base due to approaches like canary testing. The same applications can have scenarios that are extremely hard or even impossible to replicate in testing environments.  Such scenarios call for shift-right testing.

‍
Generally speaking, think of shift-left and shift-right approaches as complementary instead of adversarial. When it makes sense, use both, and reap the benefits.

Try out Waldo and learn more about how our solution will help you with Shift-left testing.