I’ve spent most of my professional life convincing businesses to shift things left — shift-left testing for software, shift-left demand and supply forecasts for supply chains, shift-left analytics to understand future implications earlier than your competition.

Hopefully that explains why it seems heretical for me to talk about shift-right testing at all.

Will shift-right testing somehow cheapen shift- left testing, making it old news? Or could it cause some teams to stop early preventative testing, just like internet memes can prevent some otherwise rational people from getting vaccinations?

Shift-right is happening anyway
With intelligent CI/CD automation, DevOps practices and cloud-native delivery of software into microservices architectures, our software pipelines are moving at such breakneck speeds that much of the activity has moved into ensuring resiliency at change time and post-deployment phases.

Shift-right everything — including testing — seems to be inevitable.

Given how software development incentives are usually aligned with delivering more features to production, faster — rather than ensuring complete and early testing, I don’t expect many organizations will let shift-left testing activities gate or delay release cycles for very long.

RELATED CONTENT: 
What constraints disrupt the software supply chain?
What a successful shift-left security program looks like

So what should we do now, allow end customers to become software testers?

No matter how much we try testing earlier in the software lifecycle, with greater automation, there will always be too much change and complexity to prevent all defects from escaping into production — especially when the ever-changing software is likely executing on ephemeral cloud microservices and depending on calls to disparate APIs.

There are several interesting vendors that offer pieces of the shift-right puzzle, and to their credit, none really touch the third rail of saying you can leave out QA teams, or call themselves ‘shift-right testing.’ That’s smart marketing.

And it doesn’t really matter, they can call it progressive delivery. Canary releases, blue/green deployments, feature flagging, and even some observability, chaos engineering and fast issue resolution workflows. All things that advanced teams do to improve quality and performance nearer to production, and even post-delivery.

Shift left, but bank right
Like a bike on a velodrome, or a NASCAR race track banking around the left turns — shift-right testing has less to do with validating what the soft- ware does, and more to do with accounting for everything the software might do under stress.

Not to be dogmatic, but I don’t consider it test- ing to put trial releases in front of perhaps smaller groups of customers who aren’t being told they are beta testing. (I wouldn’t want to be holding a pager when a graduated release doesn’t blow up until it scales to half my user base…)

It is, however, quite valid to call it validation. Or — maybe risk mitigation. Damage control. Blast radius reduction. Those are all great shift-right aspects of operational excellence to strive for.

When you are shifting right you aren’t really shifting testing at all, you are banking the track. You are engineering more tolerance into the system.

Bank-Right and build in more operational tolerance to your release track, so you can afford to Shift-Left testing and automated release, to go even faster.

You still need early testing, but all the testing in the world will never reach the asymptote of 100% perfection in production. Bank-Right approaches offer slopes and guardrails to keep the race on the track, and put out fires faster, even if the racers behave abnormally.

The Intellyx Take
Shift-Left and Bank-Right go hand-in-hand, just like design and engineering in the real world.

When you drive on a bridge, you hope that it was designed and tested using simulations to flex gracefully when confronted with a variety of natu- ral forces and traffic contingencies.

You would also want that bridge to be engi- neered and monitored post-production to provide early warnings and failsafes to mitigate risk and reduce harm if anything does go wrong.

Ultimately, we’ll see both approaches as two dif- ferent lenses for improving customer experience, no matter what they are called.