What Is Shift Left and Is It Enough?

In this post I’m going to explore what it means to shift left. Then I’ll discuss how automation can help a team shift left. Finally, I’ll discuss shifting right and how shift left and shift right really are just part of the same continual improvement loop. So what is “shift left”? The simplest definition I’ve seen is from Martin Fowler’s website:

Shift left is the process of taking a step that’s part of the value stream of software development and moving it up the timeline.

Visually, that’s simply doing this:

Ok, so what’s the big deal about “shift left” then? Most commonly, when someone is talking about “shift left,” they are specifically talking about regression testing. In a waterfall approach to software projects, testing has traditionally come after the code is complete, perhaps after a code freeze, and is the last step before the release.

Finding bugs that late in the development lifecycle can be expensive. According to James Martin, 56% of all defects are introduced in the requirements phase, 27% in the design phase, and 7% in coding (plus 10% other). Meanwhile, IBM reports the cost of fixing a security defect can average $80 per defect during the development phase, $240 per defect during the build phase, $960 per defect during the QA/testing phase, and $7,600 per defect once it’s in production. Another IBM study found that compared to fixing a defect during the design and architecture phase, it is 5x more expensive during implementation, 10x more expensive during integration testing, 15x more expensive during customer beta testing, and 30x more expensive post release. With the majority of bugs being introduced early in the development lifecycle and the cost dramatically increasing the later it’s discovered, shifting testing left becomes a really attractive proposition. I’ve already moved to agile from waterfall, so I’m good, right?
Not necessarily. Breaking your releases down into smaller, more manageable chunks that are released frequently rather than having just a couple of releases per year does help mitigate some of this risk. But to shift left, you’ll want to be sure to start considering and using tests to drive development, even in short release cycles. It facilitates collaboration as users, designers, developers, and testers have conversations early about how software will be tested. Directly translating requirements into test cases gets stakeholders thinking about how to validate the requirements are met and defects reduced. Adopting practices such as test driven development (TDD) or behavior driven development (BDD) can help your team shift left.

I already do TDD or BDD, so I’m good, right?
Again, not necessarily. To really make the shift left transition successful, you’re going to want to start automating the tests that you’re creating. Test automation can increase your test coverage, as it allows you to execute more tests in parallel than you can with manual tests. It also frees your testers from the toil of the monotonous parts of testing and allows them to focus on more valuable and fulfilling aspects of testing. Successfully shifting left means not just creating your tests earlier, but automating those tests. Implementing a full CI/CT/CD (continuous integration/continuous testing/continuous delivery) pipeline is a great way to not only execute your automated tests early and often, but can also allow you to automate your deployment to production and reduce human errors.

What else can I shift left?
While not covered in this blog post, you can shift more than just testing left. There is a lot of research and articles available regarding shift left design thinking and shift left deployment. Consider looking into those practices as well and incorporating those practices into your process.

What about shifting right?
Back to cost per defect, where are defects most expensive to fix? Once code is moved to production. And who’s one stakeholder we haven’t mentioned yet? Operations. Shifting right involves also incorporating more of a DevOps culture into your team. To shift right, we’re now talking about putting increased attention to the product after it’s been deployed to production. We don’t want to just throw the product over the wall to operations once it’s been deployed, just like we don’t want to throw code over the wall to QA after the code is written. Shifting right means increased attention put towards monitoring, observing, and analyzing log data once code is deployed to production. By shifting right, you can bring down the cost of fixing an issue that might make it into production. In an organization that has embraced a DevOps culture, focus is put on optimizing metrics such as mean time to recover and mean time to failure. These metrics and others, as well as data gathered from the production logs, are an excellent source of feedback to guide future product changes.

Test Early, Test Often
The fact that we’re talking about both shifting left and shifting right is indicative of the fact that software development is no longer a linear, waterfall process. It’s not correct to look at software systems as a project with a finite beginning and end. Changes and new functionality are released to production frequently in small, manageable chunks. In an agile team that has adopted DevOps practices, as development and deployment are now continual processes, testing must also be a continual process. Dan Ashby illustrates in a blog post how testing fits into every phase of development and operations with the following sketch.

In this context, it turns out that shifting left and shifting right really isn’t something that can be illustrated on a Gantt chart. Shifting left is about how we test and automate throughout the development side of the continual loop. Shifting right is about how we test and automate throughout the operations side of the loop.

Are you interested in learning more about implementing test automation in your warehouse management system? Check out our success stories, more of our blogs, or learn more about the Cycle platform.

This post was written by:
Brian Hnat
Director Software Engineering