# Shift Left

## Summary


A typical software development process is sequential (1970s-1990s): define requirements, analyse, design, code, test and deploy. In this process, testing happens towards the end. Problems uncovered by testing at such a late stage can cause costly redesign and delays. The idea of Shift Left is to involve testing teams earlier in the process and to think about testing at all stages of the process. 

When the software development process is viewed as a left-to-right sequential process, doing testing earlier may be seen as "shifting it to the left". The term itself can be seen as a misnomer since we are not simply "shifting" but doing tests at all stages of the process.

Shift Left as a principle started with testing but it's beginning to be employed in other disciplines such as security and deployment.

## Discussion

### What exactly do we mean by the term "Shift Left"?

The principle of Shift Left is to take a task that's traditionally done at a later stage of the process and perform that task at earlier stages. An example of this is testing. With the traditional Waterfall model, testing is done just before releasing the product into production. This means that serious problems uncovered so late can cause major redesign and long delays. **Shift Left Testing** addresses this by involving testing teams early in the process. Issues, be it in design or code, can be solved early on before they become major. In fact, shift-left is less about problem detection and more about problem prevention. 

Shift Left doesn't mean "shifting" the position of a task within a process flow. It also doesn't imply that no testing is done just before a release. It should be seen as "spreading" the task and its concerns to all stages of the process flow. It's about continuous involvement and feedback. In addition to the process changes, Shift Left is also about the people. For example, testing teams must now work more closely with development teams.


### What are the key benefits of Shift Left?

Shift Left identifies potential roadblocks and bottlenecks early on when there's still scope to change and improve design. Problems are addressed long before release without giving into pressure of an imminent deadline. There's obvious cost savings for the project since problems identified earlier are cheaper to fix. Shift Left reduces risk since many issues are addressed long before the release. Releases can be made faster with better quality. 

Automation is essential. This reduces human errors, increases test coverage and lets testers focus on more inspiring tasks. 

Since teams work closely, some level of whitebox testing can be done. It's also easier to estimate effort and plan for resources. Often debugging problems in production is hard and shift-left ensures most problems are caught much earlier, where they are easier to debug and fix. 


### In what disciplines of software development is Shift Left applied?

Shift Left is being used in the following disciplines:

    + **Testing**: It's in testing that Shift Left started. It aligns with Agile practices such as *Test-Driven Development (TDD)* and *Behaviour-Driven Development (BDD)*. For example, by doing integration testing earlier, design can be changed more easily.
    + **Security**: Security is addressed right from the development stage. When combined DevOps, we get what we call *DevSecOps*. Security standards must be in place. Security folks must use the same tools as DevOps and be empowered to fix code on their own. Shift-lefting for security is particularly important for open source code.
    + **Deployment**: When apps are in the cloud, continuous deployment has become common practice to quickly deliver latest fixes and features. The use of templates, patterns and automation streamlines this. Building, provisioning and deploying of software is automated. In fact, continuous deployment enables continuous testing.
    + **Design**: Poor requirements can lead to a product not aligned with business needs. Going beyond requirements, the entire team can adopt a design thinking mindset. Everyone would have a shared vision of the product.

### Are there different types of Shift Left Testing?

Shift Left has been compared to a production line with raw materials on the left moving towards finished goods on the right. It's also been compared to kanban boards with completed tasks moving from left to right. In all cases, Shift Left is about getting involved at an early stage, which happens "to the left".

While shift-left testing is really about continuous testing, four types have been identified: traditional shift left, incremental shift left, Agile/DevOps shift left and model-based shift left. With **model-based shift left**, testing can begin even before a software implementation is ready. Tests are against executable requirements, architecture, and design models. 


### How can I get started with Shift Left?

With regard to testing, developers can take up some testing tasks (unit tests for example) while testers need to learn to code. This will help them collaborate better and automate tests. They also need to use the same tools. By adopting TDD or BDD, a project will start with testability in mind. At the least, static testing plans, automation scripts and API tests can be written even before development starts. Test managers must move to new roles as shift-left testing could make them redundant. 

Small iterative changes along with collaboration across teams, code reviews, automation and monitoring are all part of applying Shift Left. Workflows should be defined and followed. Configurations should be immutable and scripted, avoiding ad hoc changes. Give tools and dashboards to developers for insights into production. Developers should be able to see failures at all stages. It's important to be proactive rather than reactive. 

Deployment procedures should be standardized so that the development and production environments are as close as possible. Use patterns to get consistent environments. Development and operations should work closely rather than in silos. 


### What are some myths about Shift Left?

One of the myths is that testing is done by developers and hence QA teams will become redundant. In reality, QA teams will work more closely with development teams. Developers will be aware of testing needs. Testers will get insights into what's being developed. A related myth is that Shift Left is not aligned to Agile practices. This myth is also busted since greater collaboration between QA and development teams means that they can iterate faster. 

Another myth is that the return on investment is not proven. In fact, studies have shown that fixing problems at a later stage is very costly. 

Another myth is that there are no tools to aid in shifting left. In reality, Shift Left is about processes, people and tools. Automation tools play an important role. Same tools that can be used by multiple teams, including testing tools within a development environment, ease the implementation of Shift Left. Behaviour-Driven Development (BDD), Continuous Integration and Continuous Deployment rely on automation and help accelerate Shift Left. 


### I've heard of Shift Right. Does it replace Shift Left?

No. Shift Right complements Shift Left. As of 2018, Shift Right is commonly used for testing.

Shift-left testing is about improving quality, testing often, shortening test cycles and automation. It's about checking for expected software behaviour. What about undefined, unknown or unexpected behaviours? What about performance, user experience or fault tolerance? Production environments with live traffic and real users are different from typical test environments. This is where shift-right testing comes in. 

With **shift-right testing**, testing is done in production where you may find unexpected behaviour. It involves deploying small changes to production, monitoring closely and reacting quickly if failures happen. Software deployed for shift-right testing is not done and dusted. It has to be monitored and rolled back if needed. With shift-right testing, you can gather user feedback and improve test coverage. 

Among the approaches to shift-right testing are duplicating live traffic for test purpose, A/B testing and canary deployments. **Chaos engineering**, implemented with tools such as Chaos Monkey, can be considered as a form of shift-right testing. 

## Milestones

1950

In the 1950s, software is often developed and tested by the same people. It's therefore common practice to test continuously. There are no separate testing or QA teams, which come later. 

1970

Winston Royce describes the different steps in building large software systems. In his description, testing happens towards the end of the development cycle. Royce himself clams that this is "risky and invites failure". Unfortunately, software teams adopted this approach while ignoring Royce's recommendations towards an iterative approach. This top-down unidirectional flow is later named the **Waterfall Model**.

1990

The 1990s is the decade when teams realize that the Waterfall model is not working out. The principle of Shift Left begins in this decade. 

2001

The use of the term *Shift-Left Testing* appears in an article published at Dr.Dobb's. The author Larry Smith writes,

> Shift-left testing is how I refer to a better way of integrating the quality assurance (QA) and development parts of a software project.