shift left testing

Contributor(s): Matthew Haughn

Shift left testing is an approach used to speed software testing and facilitate development by moving the testing process to an earlier point in the development cycle. Shifting left is a reference to moving testing to the left on a timeline.

Shift left testing is designed to be a better model for shift left (fast lane) development because traditional testing models that wait until later in the development cycle can bottleneck development.

Four types of shift left testing exist: traditional, incremental, agile/DevOps and model-based shift left testing:

  • Traditional shift left testing focuses on unit and integration testing through API testing and modern test tools.
  • Incremental shift left testing breaks complex development down into smaller pieces, allowing them to be tested in smaller segments that build upon each other. Incremental shift left testing is widely adopted.
  • Agile/DevOps performs testing in numerous sprints. The model is often restricted to developmental testing without operational testing. Agile/DevOps is a popular and ongoing testing type transition.
  • Model-based shift left testing includes executable requirements, architecture and design models to eliminate 45-65 percent of errors introduced in these early phases. The model-based approach is the newest trend in shift left testing.

By involving testers sooner, developers hope to catch problems earlier in the development cycle, leaving time available to correct found issues and preventing compound errors. When defects and errors are discovered earlier, less effort is wasted working with a flawed implementation. Detecting problems earlier facilitates debugging, which becomes more difficult as software becomes more complete, with more features integrated. Early involvement also helps ensure that sufficient resources are allocated for testing because testers are more involved in planning stages.

The shift left approach illustrates the common development adage and advice, “Test early and often.”

This was last updated in September 2016

Continue Reading About shift left testing

Dig Deeper on Application Maintenance on Production Systems

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Tools help with confirmatory checking of known unknown but each tiny fact adds little value. Scaling automation is hard and expensive, and it also skyrockets maintenance costs.

Tools sometimes help with discovering of traces of unknown known. And they are totally helpless with unknown unknown. The real value of testing is in discovery of these two, so the problems can be prevented before production.
What are the biggest challenges of using automated testing tools?
One of the biggest challenges with using automated testing tools is with the complexity of incorporating the oracles to validate product functionality. They only validate what we tell them to validate, and determine failure based only on what we tell them, so it’s imperative that we get the oracles right, and that can be amazingly difficult to do.
@Michael - yes; and the value of a single validation is typically very low. Even if a legitimate bug was detected, there are thousands more validations to make. It's a non-trivial task to scale automation in way that a single failure can be detected, handled, but won't cause stopping of the execution of automated tests.