The four myths of shift left testing
What is shift-left testing? It is one of the most commonly discussed trends in DevOps, and for a good reason. There are many important components of an effective continuous testing strategy and none are more critical than shifting left. In this article, Joanna Schloss dispels four myths about shift-left testing that you might have heard.
If you’ve been around technology long enough, chances are you’ve seen the process play out many times over: a new trend emerges, finds some backers, gains some momentum, and before you know it, becomes the talk of the industry. The hype machine eventually kicks into overdrive, and once it does, it can often be hard to separate myth from reality.
Such is the case with shift-left testing.
As organizations look to accelerate their agile development efforts in order to drive faster release cycles, improve functional quality, and deliver a better digital experience to their customers, shift-left testing has quickly become one of the most often discussed trends in DevOps. And for good reason. There are many important components of an effective continuous testing strategy and none are more critical than shifting left.
What is shift-left testing?
To shift left means to conduct testing earlier in the software delivery lifecycle (as opposed to the traditional approach of handing testing off to a dedicated QA team at the tail end of the development process). The logic is simple: the earlier in the development process you can execute tests, the sooner you can deliver feedback to your developers, and the more productively they can work.
As is often the case with critical new technology trends, however, shift-left testing’s rise to prominence has been accompanied by the perpetuation of numerous myths. With that in mind, let’s outline and dispel the four most common.
Myth #1: Shift-left testing is purely a technology trend
Certainly, modern tools and technology can help facilitate its implementation, but shifting left is first and foremost about how the changing expectations of customers in the digital age are transforming the way businesses build and deliver products and services. In other words, like so many of the most impactful IT trends, shift-left testing is a business trend first and a technology trend second. And business trends require buy-in and support from business leaders.
For most organizations, shifting left will represent a considerable departure from their current approach to testing, and that change will be significantly easier to orchestrate when it has the full support of company leadership. So, if you’re thinking about implementing a shift-left strategy, start with people, not processes. Outline how shifting left can help your business meet the growing need for quality at speed, and ensure you have full buy-in from organizational leaders across multiple functions before making the necessary investments in technology and changes in procedure.
Myth #2: Shift-left testing is a one-time initiative
Done right, shifting left is far more than a one-time initiative you implement for a given product release or a particular sprint. Rather, shift-left testing is a continuous endeavor, akin to a (hopefully permanent) lifestyle change. Every sprint, every release, every time.
Your goal should be to get to a point where you’re developing tests at the same time you’re writing code, ensuring your developers never have to sit around for hours or days waiting for feedback. If you wanted to push it a step further, you can aim to script tests before you even start the coding process, something ultra-progressive development teams have already started doing. Not coincidentally, these are the teams you hear about delivering new releases and critical app updates on a daily if not hourly basis.
But wherever you start and wherever you hope to wind up, just remember that there’s no finish line. Shifting left means making early-stage testing a permanent part of your development strategy and continuously working to push the boundaries from there.
Myth #3: Shifting testing left means deploying the same test strategy, only earlier
If you’ve yet to implement shift-left testing, chances are your current test strategy involves running a series of end-to-end regression tests aimed at testing the compatibility and functionality of your entire application workflow, and doing so at the end of the development process. Shifting left does not mean you simply take those same end-to-end tests and run them earlier in the process. You don’t have the time (or need) to run full cross-browser, end-to-end tests while your developers are still in the early stages of writing code.
Early-stage testing is about getting fast feedback to your developers. Developers should be able to test code as soon as they write it, get feedback immediately, quickly make any necessary adjustments, and continue on loop throughout the development process. So, keep your end-to-end tests where they are – at the end of the process. Instead, when you’re early in the development cycle, emphasize short, atomic tests that focus on singular pieces of application functionality.
Myth #4: Shift-left testing is only about the early stages of the development process
Shifting left is about delivering quality applications at speed and providing the flawless experience your customers expect and demand when engaging with one of your digital properties. And make no mistake, shifting left and testing in the early stages of the development process is a huge part of the equation. But it’s not the entire equation. If you’re serious about successfully shifting left, then you need to do so as part of a holistic continuous testing strategy, one in which you’re automating tests throughout every stage of the development process.