Analyst View: Shift testing left, but bank right
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.
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.
Credit: Source link