Shifting left is the concept of incorporating specific practices, which have traditionally been left until late in the process, much earlier in our workflow.

System integration, testing, user experience, and deployment can all profoundly affect the outcome and success of our product; they all validate the product's viability in different ways. If we start thinking about them sooner in our development life cycle and we start to build these strategies as we go, we have a much better chance of success and of avoiding any nasty surprises.

The following diagram shows what we mean by shifting left:

By moving these practices towards the beginning of our product development life cycle, we will start to get feedback sooner that these aspects of our product will work.

For example, in a linear development process such as a gated waterfall approach, we often leave a full integration and system test until the end of the project. This creates several problems:

• Taking the "big bang" approach to system integration often uncovers many false assumptions that were made, and therefore many changes will be required. It will be costly, with days or even weeks of lost time.
• A large-scale test at the end of the development cycle will often find numerous problems that need to be fixed. Sometimes it will discover fundamental issues that require substantial reworking, or even going back to the drawing board. 

In the same way, I've seen user interaction and graphic design left until the end of the development cycle. These specialists are often brought in late to the project, with the hope that they will make things work better or make things look nice. Unfortunately, if making things work better or look nice involved significant changes to the user interface, it would also often require a substantial shift in the architecture of the application.

Simply put, by working on the things that could have a profound effect on the outcome of the product sooner, we reduce risk. 

The following graph shows the relative cost of fixing deficiencies depending on where they are found in the software development life cycle:

Defects in software are anything that doesn't work as intended or expected, whether it's a miscommunicated, misunderstood, or poorly implemented requirement, or a scalability or security issue. 

We uncover defects by moving increments of working software through our system to "done" as quickly as possible. To do this, we have to incorporate all aspects of software development, often starting with UX, as well as testing and deployment strategies from the outset. We don't expect to build all of these in full the first time around. Instead, we plan to do just enough so that we can move to the next increment and the next, iteratively improving as we go.