Why do we shift left

Shift left testing is important because it helps to prevent the following types of harm due to late testing:

Testing early is a design methodology that causes the design to emerge from genuine needs, not ‘I might need this’
Without it many requirements, architecture, and design defects are not uncovered and fixed until after significant effort has been wasted on their implementation.
Debugging (including identifying, localizing, fixing, and regression testing defects) becomes harder as more software is produced and integrated, unless the code is written to be decoupled, and writing lots of tests forces this decoupling
Without shift left, there is less time to fix defects found by testing, thereby increasing the likelihood that they will be postponed until later increments or versions of the system, which creates a “bow wave” of technical debt that can sink projects if it grows too large.

What are examples of shift left testing

Have performance tests running on the first week of a project, even when the only thing to test is ‘keep alive’
- Because every time we add functionality we should performance test it
- If we performance test early and often we can detect bad things we introduce into the architecture when we introduce them
Have security tests running as soon as possible, even when the code base is tiny
- Deal with security issues early: ideally as soon as a feature is added
Have features tests written as the stories are developed
- You can use a language like cucumber, or just plain xUnit tests.
Implement contract tests before the end point is written
- Ask the consumers who are working on the same story with you to give you their first thoughts on a Pact test and use that to drive your development
Write unit tests while actually writing the code, instead of waiting until the end of the job.
- Forces the code to be simpler, and easier to test