Shift-Left vs Traditional Testing: Choosing the Best Approach

The idea of shifting testing to earlier phases in the software development lifecycle (SDLC) has gained momentum as the cost and time spent on fixing bugs found through traditional testing models grew. In fact, 87% of companies take this agile approach to software testing.

The goal of shift left testing is to reduce the number of bugs found in a project's code by performing early and frequent tests on your software development initiatives.  

In this article, you will learn whether shift left testing is the right framework for your project as well as how to get the most out of this approach.

Traditional Testing, Shift Left Testing, and Shift Right Testing: What's the Difference?

Testing is an essential part of the product development process because it helps ensure that what you are developing will actually work when completed. 

One of the best ways to visualize production is to imagine a conveyor belt running through a factory. Different components are added before forming a completed product as the process moves along its journey.

But where is the optimal point in the process to test? This question has been hotly debated among experts for some time now. 

Some argue that testing needs to be performed when your application programming interfaces (APIs) and graphic user interfaces (GUIs) are complete, while others feel there are areas worth testing before they're deployed.

They typically fall into two camps: traditional and agile or shift testing (with the new majority finding themselves here).

Traditional Testing

This approach to testing often happens before this final stage (the right side of the conveyor belt versus the left, if you will), which makes sense because there's more product to check for errors.

That being said, the use of traditional, manual testing methods to verify the safety and functionality of a product immediately before releasing it into production has its difficulties. 

Since this testing occurs so late in the development cycle, the discovery of bugs or usability issues often leads to a delayed release until those problems have been fixed, causing a bottleneck.

This led many companies implementing traditional testing to start doing unscheduled releases, so these issues don't hold up progress anymore.

In addition, as you get closer to the finish line, the cost of fixing those bugs and flaws skyrockets. This fact alone may cause major cost and budget overruns that can delay or even derail the entire project.

Source: www.stickyminds.com

Pros: 

• Identifies the maximum number of defects due to its incremental process.
• Ensures a quality product due to issues being resolved before pushing the product live.

Cons:

• Impedes time-to-market due to the scope of the changes that need to be made to fix even simple flaws.
• Adds increased cost for extensive documentation and time needed to complete resolutions.
• Unexpected errors may occur if the requirements are modified or poorly communicated.

Shift Right Testing

Unlike traditional testing, this form of agile testing initiates testing post-production or all the way to the "right" of that conveyor belt.

Using a shift right approach, you will test a complete and functioning application to ensure performance and usability. Targeted users provide feedback on their experience to improve the software even further.

Common testing techniques that utilize right shift testing include:

• A/B testing
• Canary deployment
• Chaos testing
• Fault injection testing

While this agile approach allows you to collaborate with users to enhance your product, this testing is only effective in a post-production environment. It needs to be supplemented with shift left testing to give you comprehensive results.

Pros: 

• Enhances customer experience due to its continuous feedback loop from its users.
• Uncovers critical issues by finding bugs that occur in a live environment and letting developers modify features as needed.

Cons:

• Limited scope since it can only test fully developed environments.
• Unforeseen costs and risks may arise trying to implement changes in complex environments.

Shift Left Testing

To prevent bugs from becoming big, costly problems, shift left testing literally pushes testing to the "left" by identifying and resolving issues as early in the development process as possible. 

It's important to note that shift left does not mean shifting your testing to an earlier stage and neglecting to test again.

On the contrary, shift left testing encourages developers and testers alike to start testing sooner and continually check for errors rather than just focusing on one stage of development at a time.

With APIs, the key is to be able to test a functional application as early as possible so that you can exercise all the functionality and see if there are any logic flaws, loopholes or security vulnerabilities.

For example, to address a BOLA/IDOR flaw in an app, you'd want to run tests to validate that User A is not able to view/modify/delete a transfer belonging to User B.

The USPS data breach is a perfect example of that vulnerability in action - where a user was able to authenticate and then look up any other user in the system, including their email address, phone number, street address, and other PII.

The main benefit of shift left testing here is that if there is a flaw in the application, you're going to find it before it goes to production, where someone malicious might find it first.

This methodology requires more than just process changes. It's also about shifting the mindsets of those involved so that they continue to provide feedback throughout each stage.

Shift left testing is a great way to avoid problems before they start, not just react after the fact. The more tests a developer runs before pushing their code to version control, the better.

Pros:  

• Increases delivery speed since problems are addressed and resolved well before the product is released.
• Reduces cost as it finds errors earlier, which are typically cheaper to fix.
• Improves quality since the changes to design and functionality are made throughout the entire process versus trying to remedy the finished product.

Cons:

• Needs a culture change for the process to be correctly implemented. 
• Requires myth-busting that some team members may have about the process; for example, QA teams and developers work closely together during testing versus QA teams becoming obsolete.

Documenting best practices for shift left security devops, such as policy-as-code and automated API regression testing, makes it easier to scale security across multiple product teams.

How to Maximize Your Shift Left Strategy 

The best way to apply shift left testing is with small iterative changes that are made across teams. Here are some changes to start implementing:

1. Understanding the Difference Between Testing the Entire Process vs. Processes in Time

As a first step, you'll need to help your team understand the benefits of shift left testing by identifying how this approach needs to be applied across the entire SDLC, not just as a process in time.

The best way to reduce risk is by performing testing at various stages and continuing your efforts as you move down the line. Remember, shift left testing doesn't mean moving testing to an earlier stage and neglecting to test later on.

This will lead to an inefficient process with missed defects or vulnerabilities that could have been remediated if they had been tested more thoroughly.

You'll want to focus on:

• How will testing at an earlier stage mitigate risks?
• What is the earliest stage that will provide actionable information?
• What are the risks if we don't test at this point?

2. Avoid Waste During Shift-Left Testing

While testing earlier in the process is the main goal of shift left testing, there is a fine line between testing early and practical testing.

This means that you don't want to shift your testing too far to the "left" that it occurs before it will provide actionable information.

To avoid creating shift left testing waste, you need to evaluate:

• What are you doing currently in the process?
• Why are you doing this at this point?
• Can you test parts earlier in the process?
• If you test earlier, what is the risk for waste?
• What testing spots will allow you to pass the most information forward?

3. Encourage Collaboration for Developers and Testers

In a shift left approach, developers and testers are supposed to work together.

When developers test individual units, they are able to achieve a higher level of quality code before it is merged into the main system.  

Additionally, QAs should know some basic coding to help them be more effective. Coding skills allow testers for quick fixes wherever possible, which will make their job easier when it’s time to fix bugs.

To encourage maximum collaboration, you'll want to ensure they have access to the same testing practices, like Test-Driven Development (TDD) or Behaviour-Driven Development (BDD). This encourages everyone to stay on the same page.

‍

4. Deploy Automated API Testing Solutions

APIs account for 80% of total internet traffic, and Gartner even reported that APIs are well on their way to becoming the main attack vector in 2022.

Since APIs are the backbone of many digital efforts, you need to ensure they are secured. 

Without an automated testing solution, shift left testing is relatively ineffective because you'll accrue major development costs along the way.

One way to mitigate this is to use a tool that makes it possible to reduce or eliminate the need for additional dev resources.

Partnering with an automated API security testing platform, like APIsec, lets you perform API security testing for every release and time you change the source code. 

The platform will analyze the APIs architecture, develop tailored attack scenarios, execute playbook attacks, and generate a comprehensive report.

Find out how APIsec is helping businesses harness the full power of the shift left approach by contacting a specialist.

‍