The ROI of Shift-Left Testing

Perhaps the “shift-left” term has become overused and is stepping solidly into buzzword territory – but the fact remains that testing early and often has proven ROI.

Shift-Left refers to introducing QA sooner into the product release cycle. Gone are the days of waiting for a product to emerge from the development team and testing to begin. Just as Agile changed the traditional waterfall approach into more frequent iterations, just as DevOps and CI/CD drove efficiency, Shift-Left is introducing testing early and often.

Shift-Left dramatically improves quality. Shorter sprints are tested, bugs are found earlier and potential show-stoppers are avoided. Arguably it also forces more quality awareness on behalf of developers who know the code they check-in will be immediately tested. Shift-Left also helps the process be more efficient and makes QA more fundamental within the CI/CD pipeline.

The benefits of better quality and better efficiency are clear.

However, what is often overlooked is the tremendous cost-savings that comes with Shift-Left and why it has such a compelling ROI.

The later bugs are found in the product release cycle, the more expensive they are to fix. Put another way, it costs much less to find bugs that are discovered early.

As depicted above, the cost increases linearly with the lateness of their discovery. Fixing a post-production bug is 10x more expensive than catching it early on.

Clearly your mileage may vary, both from a cost per defect point of view and the increased cost per phase. Consider too that this only factors in actual development cost, and does not consider the other ramifications of bugs found later on, including app abandonment, poor app store reviews and generally hurting the brand of the organization.

Manual or Automated Testing?

The Shift-Left philosophy doesn’t dictate the manner of testing. However, the more successful implementations of testing early-and-often will typically utilize both manual and automated testing.

Manual testing is great for new functionality testing and ensures that quality is injected for all new development. However, in order for QA (and shift-left) to work in a CI/CD environment, it is typically necessary to have great automated tests, specifically for regression testing.

How do we get started?

Think of Shift-Left as part planning, part mindset and part action.

Planning means looking at your entire development and testing lifecycle, and integrating testing throughout the lifecycle on your project plan. Too often, organizations expect the shift-left testing to happen “behind the scenes” and do not adequately plan for this continuous activity, either in time or resources. This often causes a false start for shift-left testing due to lack of prioritization. Shift-Left should be fundamentally a part of your project planning.

Mindset refers to orientating developers to the idea that their code will be tested early and often. This often requires more attention during the development cycle and a change in attitude. It requires developers to think more about edge-cases and overall quality before checking in their code. Developers should come to appreciate the QA are catching errors early and often, and not view it as an annoyance slowing down their development.

Action means getting started, and not let Shift-Left languish in the planning phase or be a “nice idea to look at later”.  You don’t need to perfect this from day one. Indeed, it’s almost impossible to plan the perfect switch to shift-left. It’s a philosophy – just get started and keep improving.

Conclusion

Better quality and better efficiency are compelling enough to warrant the move to “shift-left”. However, the ROI and reduced cost associated with catching bugs earlier should move this solidly into “no brainer” territory! You may stumble along the way, but the risk is low, the benefits are high.