What is shift-left testing?
Explore IBM's shift-left testing solution Subscribe to AI Topic Updates
Diagram showing how shift-left testing works
What is shift-left testing?

Shift-left testing is an approach in software development that emphasizes moving testing activities earlier in the development process for improved software quality, better test coverage, continuous feedback and a faster time to market.

Have you been involved in a software project that ran over budget and blew past every deadline? Of course, you have–we all have. In fact, if you haven’t, you are a unicorn and I would like to hear from you.

Early stages in my software development career, I learned the importance of working backward from a deadline. If a project must be done by a certain date and testing will take a certain amount of time, then we can use that information to work backward and choose a due date for our project. Perfect, right?

Well, not quite. While building in time for manual testing reduced some stress in the final days of projects, there were still too many surprises.

Building in time for QA testing is great in theory but quickly falls apart in practice once the first bug or defect is identified.

How long will this defect take to fix? How much will it impact the timeline? Will new bugs be introduced? How will we ensure each fix is verified with time to fix anything we broke while we were fixing the first thing?

Ultimately, I was never able to find the correct amount of time to allocate for QA. Inevitably, rushed fixes were merged at the last minute; I learned to keep my calendar clear for a couple of weeks after big launches so that I could triage all of the issues we missed (or introduced) in our mad dashes to the finish.

The problem, at the end of the day, was not the time available for testing but rather the timing of the testing. I needed testing sooner and more often. I needed shift-left testing.

If we imagine our software development process as a timeline flowing from left to right, then “shift-left testing” becomes somewhat self-explanatory. Simply put, it is the practice of testing earlier stages, involving team members, including testers, developers and stakeholders in the testing strategy, and integrating testing for both existing and new features more often in the development life cycle.


The Total Economic Impact™ of IBM Robotic Process Automation

See a cost and benefit analysis of IBM Robotic Process Automation (RPA).

Related content

Read a guide to intelligent automation

The V-model of software development

The V-model is a useful way to conceptualize software development cycles. If we take the traditional waterfall flow and “flip” the Y-axis at the implementation phase, we get the V-model.

A development cycle begins with high-level requirements. These requirements are narrowed down with each successive step down the “V” until we reach the code-level implementation itself. We then verify the implementation, starting with the most granular unit tests and working our way up the “V” to more abstract user acceptance testing.

In a waterfall process, the entire project is made up of a single “V.” As an industry, we have learned that when you leave all of your validation to the very end of a complex project, you are basically setting yourself up to fail.

In an iterative process, we can think of each sprint or iteration as a smaller “V.” We have theoretically achieved our goals of shift-left: testing sooner and more often. Problem solved, right? Well, not quite.

Types of shift-left testing

You may have noticed that there are two labels on the feedback channel built into the V-model: verification and validation. These are both important.

We need to validate that our user requirements actually solve the problems we set out to solve. We also need to verify that our implementation matches the specifications we get from those user requirements.

Automated testing can be applied to both validations and verifications. BDD (Behavior Driven Design) has led to the creation of technologies such as Cucumber that can automate some parts of the validation process. For the purposes of this article, we will focus on automated testing for verification.

Unit testing

Unit tests verify the functionality of a specific module within a larger application. The module is tested in isolation, and any communication with other external processes is simulated or mocked. Unit testing and TDD represent the first development phase in shift-left testing.

Integration testing

Integration tests attempt to verify the overall functionality of a service or application, including side effects. This process is an anti-pattern for reasons we will discuss later.

API testing and contract testing

API tests verify the external endpoints of a single service. The scope of API tests is similar to the scope of integration tests; However, in an SOA or microservices context, we can think of API tests as the new unit tests.

UI testing

UI tests verify the complete functionality of an application from the user interface layer. Tools like Selenium make automated UI testing widely accessible.

More than just automation

Shift-left isn’t just about automation. Another way to test earlier and more often is to make sure that your QA specialists are involved in every step of your process, beginning with discovery and requirements gathering. Test engineers can do better when they have a greater understanding of the overall implementation, and their insights can help make the architecture more transparent and resilient.

How to get started with shift-left testing

When we think of testing “sooner and more often” a certain word comes to mind: continuous. Many (most) software development teams are practicing some form of continuous integration and continuous delivery. Continuous testing is a vital feedback loop in this DevOps cycle.

Continuous testing

If we think of TDD as “shift-left for monoliths,” then continuous testing is “shift-left for distributed architectures.”

TDD had us focus on unit testing. For continuous testing we should focus on API and contract tests. API tests have a number of benefits:

  • API tests can prevent one of the most common ways to introduce errors in a microservice application: changing a dependency out of sync with its upstream or downstream services.

  • API tests can be owned by the same team that owns the service.

  • API tests avoid the brittleness of testing side effects and implementation details.

Ideally, these API tests will be run continuously against both production and pre-production environments. Contract testing tools can help automate this process, but that requires additional infrastructure.

What if we could use continuous API testing built into our observability tool? The upcoming synthetic API testing feature from Instana will let you continuously run API tests against all of your environments with minimal effort.

Best practices for shift-left testing in agile development

Shift-left involves moving the testing activities closer to the beginning of the software development lifecycle, enabling faster feedback and reducing the time and effort required for bug fixing. Here are some best practices for shift-left testing in agile development:

  1. Early involvement: Testing activities should begin as early as possible in the development process. Testers should be involved from the requirements gathering phase to understand the project scope, objectives and user expectations.

  2. Collaboration and communication: Foster close collaboration and communication between developers, testers and other stakeholders. Encourage daily stand-up meetings, sprint planning sessions and regular retrospectives to ensure shared understanding and alignment.

  3. Test automation: Invest in test automation to enable frequent and efficient testing. Automated tests should be created alongside the development process and integrated into the continuous integration and deployment pipelines. This helps in detecting defects early, reducing regression issues, and speeding up feedback cycles.

  4. Test-driven development (TDD): Encourage the practice of TDD, where developers write test cases before writing the actual code. This shift-left testing approach helps in defining the desired behavior and expected outcomes upfront, leading to more robust and testable code.

  5. Continuous integration and continuous delivery (CI/CD): Implement CI/CD pipelines to automate the build, test and deployment processes. This practice ensures that each code change is thoroughly tested and deployed to production environments quickly and frequently, reducing the risk of integration issues.

  6. Shift-left security testing: Consider integrating security testing practices early in the development process. Conduct security code reviews, static code analysis and security-focused testing to identify vulnerabilities and address them proactively.

  7. Exploratory testing: Alongside automated tests, encourage exploratory testing to explore the application from a user's perspective. Skilled testers can identify potential usability issues, edge cases and scenarios that automated tests might miss.

  8. Performance testing: Do performance testing early to identify potential bottlenecks and scalability issues. This helps in optimizing the application's performance and ensuring that it meets the required performance criteria.

  9. Test environments and data: Provision test environments that closely resemble production environments to ensure realistic software testing. Also, ensure that sufficient and representative test data is available to simulate real-world scenarios.

  10. Continuous learning and improvement: Foster a culture of continuous learning and improvement. Encourage regular retrospectives to reflect on testing processes, identify bottlenecks, and implement changes to enhance the effectiveness of shift-left testing.

By implementing these best practices, agile teams can achieve better collaboration, faster feedback and higher-quality software products through shift-left testing.

The benefits of shift-left testing

The shorter feedback loops built into shift-left processes empower us in several ways. Defects can be found faster, fixes can be applied more efficiently, and lessons learned in one iteration can be applied in the next, to name a few.

Whatever project management methodology or release cadence your team has, you can benefit from the shorter verification feedback loops from shift-left testing.

Cost savings

A defect found by an automated unit test on a developer’s local machine costs less to identify and fix. But when a defect has made it all the way to a customer-facing environment, the cost to fix it increases.

Developer wellbeing

When done properly, automated testing and CI can provide the confidence that software engineers need to deploy often—even on Fridays. Finding defects sooner means fewer panicked all-hands moments. Since releases are so painless, fixing the few errors that do make it through is faster and easier too.

Resilient architecture

Just as more accessible software is usually easier to use for all of us, more testable software can be easier to reason about and maintain. Thinking about testing early can lead to better separation of concern and a more resilient overall architecture.

Greater overall quality

Improving the customer experience is our ultimate goal. Shift-left can eliminate some incidents that end users might experience and reduce the impact of other incidents. We can use observability to complete this feedback loop and improve our overall software health.

The dangers of shift-left testing

With powerful automation tools at our disposal, it can be tempting to implement every kind of testing on every line of code. This is a dangerous path.

Testing side effects—did that record actually get saved to the database?—is an attractive idea. But testing implementation details is an anti-pattern because these types of tests are extremely brittle. They might need to be changed every time your application is changed. The user interface is also an implementation detail, so UI tests land in this same boat.

Verification tests just care about the “what,” not the “how” or the “why.” Ideally, the user requirements have been designed to validate “why.” To answer “how”, we can rely on a more powerful automation in the form of an observability platform.

Shift-left vs shift-right

Shift-right testing is the practice of testing later in the development process, usually in production environments. While it may seem strange, shift-left and shift-right testing are complimentary.

Shift-right testing allows us to identify production issues before our customers do. The shorter feedback loops from shift-left testing give us the ability to respond to and remediate these production issues rapidly.

Synthetic API testing as a part of your observability platform is the perfect way to combine the benefits of shift-left and shift-right practices.

Shift-left products
IBM Instana™

Boost functionality and observability in your enterprise APM; improve application performance management and accelerate CI/CD pipelines no matter where applications reside.

Explore IBM Instana

Shift-left testing resources What is observability?

Explore how observability provides deep visibility into modern distributed applications for faster, automated problem identification and resolution.

What is continuous testing?

Read how continuous testing plays a crucial role in accelerating software development, improving code quality, and avoiding costly bottlenecks.

What is DevOps?

Explore how DevOps speeds delivery of higher-quality software by combining and automating the work of software development and IT operations teams.

What is synthetic monitoring?

Learn everything you need to know about synthetic monitoring including what it is, how to use it, the challenges and more.

What is automation?

Learn how the application of technology, programs, robotics or processes can help achieve outcomes with minimal human input.

What is application performance management (APM)?

Predict and prevent performance issues before they impact your business with application performance management.

Take the next step

IBM Instana provides real-time observability that everyone and anyone can use. It delivers quick time-to-value while verifying that your observability strategy can keep up with the dynamic complexity of current and future environments. From mobile to mainframe, Instana supports over 250 technologies and growing. 

Explore IBM Instana Book a live demo