What on earth is shifting left?

If you exist in a space that is closely aligned with technology and you work with or around consultancies you may have heard the term “shift left”. Like me when I first heard the term you may have feelings of “is this another corporate buzzword?”. For the most part, you are correct. However, if we can see past this consultancy spiel we can identify the value that lies below.

So what on earth is “shifting left”? 

Phrases like “shift left” are the perfect specimen to vindicate a general inability to communicate ideas effectively. Great ideas and frameworks become locked behind acronyms and corporate speak. 

If we dissect the term “shift left”, “shift” gives us ideas of positional movement. Maybe moving people or equipment. However, the shift is about a project timeline. If only we had a word to describe something that happens during the first part of a period. I don’t know, something like “earlier”?

The second question you likely have is what are we shifting? Testing. How about we replace “shift left” with “test earlier”? Genius Jake, put that on your master agile Jedi consultancy board and sell it to the masses.

Yes. Generally, when people say shift left (at least in software) they mean test earlier.

Now we have managed to wade through the consultancy gatekeeping what does this actually mean for your testing strategy?

Whenever somebody starts talking about testing early I think about Test Driven Development (usually shortened to TDD by the acronym brigade. See developers do this weird re-naming stuff so nobody knows what they are talking about too). This is to write your tests before you write a line of application code. Then write code to make your tests pass. This approach only covers unit testing. What about performance testing. We can’t do performance testing before we have written the code. So “shifting that left” doesn’t make sense here. It’s not just about testing earlier but identifying when is the earliest point it makes sense to start testing. This way we can test early, fail fast and iterate more often. 

The sentiment behind shifting left is spot on. The legacy strategy was to write all the code then test all the things. If you have ever looked into the eyes of a developer who has to fix 60 defects and 30 accessibility bugs at the end of a project and a day before ‘go live’ you will understand why testing at the end may not be most advantageous.

As we transition our approach from projects to products, we move away from phased approaches of design, build & test to a less rigid iterative approach where testing happens as early as makes sense and doesn’t become the typical blocker/gatekeeper for realising to production.

By testing earlier in the timeline we can tease out issues with integration much sooner. By addressing these issues early on in it becomes easier to make required architectural changes to an architecture and code base that isn’t completely matured and baked in.

Moving to test earlier gives us room to breathe, iterations are more frequent and battle-hardened fixes are agreed and implemented rather than a day zero hail marry.

Finally, please stop saying “shifting left”. Nobody knows what that means. Instead go with “test early, test often”.

fsqs registered logo