Shift left vs Shift right: When to use which?

Ever since the Agile model and associated methodologies like DevOps, Kanban, and Scrum became fixtures in software development, the term “shift left testing” has gained immense attention. Much like Agile principles, the shift left approach is meant to facilitate faster release of new products and features. By fitting into Agile pipelines and removing bottlenecks early in the cycle, shift left testing follows a circular, iterative approach to QA. Unsurprisingly, it has become an essential part of Agile SDLCs.

However, as customers expect increased levels of flawless functionality from their apps and websites at all times, shift left testing is complemented by another QA phenomenon: shift right testing. Naturally, it is common for teams and companies to ask “shift left vs shift right”? 

This article will try to answer that question and offer some insight into the efficacy and applicability of shift left and shift right testing. 

Shift Left Testing

In traditional SDLCs, testing begins at the very end of the pipeline. Shift Left Testing literally moves testing to the “left,” i.e., to earlier in the pipeline. QAs use shift left tests to detect and fix bugs as early as possible in the development pipeline. This reduces the time they might otherwise have to spend fixing the same issues later in the pipeline, by which time they might have magnified and become much more difficult to isolate and eliminate without breaking some part of the software.

In practical terms, this translates to more tests being run by developers themselves before they push their individual code units to version control. There are a number of tests every developer should run to contribute to the success of Shift Left Testing and push better products.

When designing shift left tests, teams must prioritize the following:

• A thorough study of application performance, client requirements, and user expectations
• Prioritizing the creation of robust unit, integration, and functional tests
• End-to-end automation of testing funnels
• Adoption of TDD and BDD-driven tests. 

For a deeper exploration of Shift Left Testing and its benefits, have a look at Shift Left Testing: What It Means and Why It Matters.

Shift Right Testing

Shift left involves moving tests earlier in the dev cycle, and shift right is the other extreme – moving tests to the “right”, i.e. testing, the product after it has been released to end-users. The intent is to evaluate how the application performs in real-world conditions. Through shift right tests, teams can monitor how the app and APIs perform, as well as gain insights into usability and user perception. 

Shift right reveals how the software responds to unfavorable situations. Such insights and usage data are essential for teams to continue building on and improving software quality by optimizing new features or adding new ones.  At a high level, this mode of testing aims to:

• Identify user preferences through A/B testing or Blue-Green deployments. They help you judge if users prefer one version over another. 
• Establishing backend stability through canary tests and dark launches. In this category of tests, you release new code incrementally to check if it disrupts with normal functionality. 
• Detect production issues as early as possible. For example, monitoring how much real traffic and user request load the application can actually handle, is something not easy to test in pre-production environments. 

Shift right testing is quickly becoming an important component of DevOps, as it helps further bridge the gap between development, QA, and Operations teams. By setting up a continuous feedback loop, testers continue to share responsibility with devs and Ops personnel, extending the DevOps mindset into post-production management. 

Benefits of Shift Right Testing

• Scope for expanding automation: Intelligently implemented automation is at the core of good DevOps. Tests within the shift right principle, such as feature flags, canary tests, and dark launches, provide excellent scope for automation. They help automate feature releases, keep teams updated on software performance and promote optimal use of time and effort.  
• Helps roll out better user experiences: Shift right tests do more than just collect customer feedback. They translate such feedback into improvements, which benefits the software technically and boosts its business value. Quite simply, it helps teams quickly fix what users want them to fix.  
• Expands test coverage: When you start shift right tests, you expand test coverage beyond software release. By continuing tests in production, you increase the chances of identifying and resolving bugs that would otherwise contribute to an undesirable user experience. 
• Fact-based learnings for future projects: By monitoring user experience and real-world software behavior, teams can get invaluable data on what users within certain demographics tend to like, not like, and be indifferent to. In future development projects handling software of similar nature, these data points can help with creating specific development and test design documents.
  
  It also helps ascribe time and effort to features and capabilities that really matter. For example, if previous shift right tests for an e-Commerce have shown that users in a country don’t care about using in-app social media integrations, devs can deprioritize the feature and focus on creating software abilities higher on users’ priority lists.

Shift Left vs. Shift Right Testing

Source

With a closer understanding of the difference between left and right shift in testing, it’s easy to reframe the question of “shift left vs shift right”. Shift right testing does not replace shift left testing. They complement each other.  You’re meant to use both in order to give users a comprehensively positive experience when you using your website or app. 

Shift left testing aims to execute quick, automated, repetitive tests to identify bugs and possible risks at critical phases of software development. The shift right approach monitors user behavior, usage, performance, and security metrics to verify software operability in the hands of its actual users.

While the former seeks to catch and eliminate bugs as early as possible, especially before they metastasize into issues intertwined with the software architecture. However, it is not humanly possible to capture every bug because testers cannot predict every real-world condition the software may have to adapt to.

With shift-right testing, the team can be quickly notified of any bugs or optimization opportunities they missed. As user feedback informs them of disruptions in experience, they can iron out anomalies or gaps in performance so that users do not have to keep dealing with a sub-par UX.

Additionally, shift right testing does help reduce the gap between testers and Ops teams, while shift left is more effective at facilitating collaboration between developers and testers. Therefore, implementing both shift left and right strategies is an excellent way to inject DevOps best practices across the software lifecycle – development, testing, and post-production optimization. 

So, where do real browsers and devices come in?

Obviously, you can’t run shift right tests in your real device cloud; that is left to the actual end-user devices. However, you can expand test and device coverage in shift left tests by choosing a real device cloud that offers real user conditions to test in. 

If shift tests are sufficiently extensive, then far less bugs would show up in shift right tests. Users would have less reason to deliver negative feedback or develop negative reactions to your brand. Devs, testers, and Ops folks involved in releasing software don’t have too much of their time consumed by analyzing and fixing post-production bugs. 

With access to a device cloud of 3000+ real browsers and devices, such as the one provided by BrowserStack, your shift left tests will have the advantage of revealing exactly what a site or app does in the hands of end-users. Whether they use iOS, Android, Mac, Windows, Google Pixel, Oppo or other popular devices, software functioning on the same device can be verified from the comfort of your home, thanks to our remote testing options. 

Simply sign up for a free account on BrowserStack, and you’ll get:

• On-demand access to 3000+ real browser & devices. 
• An exhaustive range of real desktop and mobile devices (Android, iOS, Windows, Xiaomi, Motorola, HTC, OnePlus) configured for website and app testing. 
• Tools to debug apps & websites instantly using device logs, browser console and network logs, crash logs, video recordings, and screenshots for every test.
• Local Testing for testing on internal dev and staging environments. Creates a secure, persistent tunnel between your local development/staging environments and the BrowserStack Cloud.
• Parallel testing to accelerate by running tests simultaneously across mobile devices – reducing test execution time by more than 10x.
• Integrations with tools and frameworks to facilitate automated testing, CI/CD alignment, app distribution, and more. 
• Accessibility testing to ensure accessibility for disabled or otherwise challenged users.
• Speed testing to check website speed on popular mobile devices across manufacturers and platforms. 
• Uncompromising security & privacy. BrowserStack is SOC2 Type 2 and GDPR compliant. It also ensures pristine devices for each test. All browsing data is completely destroyed with every logout.

Get instant access to 3000+ real devices

If you’re new to testing on the cloud, consider BrowserStack Test University, a free portal dedicated to courses that will introduce testers to running manual and automated QA on real browsers and devices.   This hands-on setup lets you run tests on BrowserStack Demo, a production-grade web app capable of simulating real-world user circumstances.