As more teams embrace the challenges of continuous delivery, we hear lots of people talking about “shift left” and “shift right” in a testing context. What does that mean, exactly, and why does everyone want to do it?
When Software Development was Linear
I joined my first “waterfall” process project back in the mid-1980s, as a developer. It was a linear progression, and in my head, I saw it unfurl from left to right. It seemed reasonable (to my naive eyes) to start with a thorough analysis of the system to be built, finding out what the customers wanted. This “phase” produced an analysis document which triggered the “requirements phase”, during which analysts and product managers created a document detailing every bit of functionality to be built. And on it went, handoffs from one phase, and often one team, to the next, with thick Word documents changing hands, until the developers finally “froze” the code so that no more changes could be done. Finally QA could start the testing phase, usually with very little time left until the release deadline!
That sounds awful, and it often was, because waterfall seemed to go hand in hand with a lack of any proper development practices or any thought to building a quality product. Waterfall teams using solid development, testing, and deployment practices did fine, as long as their customers didn’t need changes more than once or twice a year. Alas, phased-and-gated projects were too often plagued with poor quality and dragged down by technical debt.
Whether dysfunctional or not, waterfall projects were definitely linear. They had a clear starting point, and a clear end. Once the project was released to production, software development teams turned the work of making sure production was working over to Operations, kicked back for a little rest after the arduous rush to finish, and started on a brand new development project.
Shifting Gears to Shift Left, Shift Right
With the advent of a much more competitive and fast-moving software world in the 90s, releasing once or twice a year was a losing strategy for companies in many business domains. The end of the century saw the rise of agile development approaches. We started slicing features down into manageable chunks. The entire delivery team started working closely with customers to understand what they wanted and delivered incrementally and iteratively. We started learning a whole lot of ways to build quality into our products as we embraced agile and DevOps practices and principles.
I think when people say “shift left” today, they may retain a bit of that waterfall thinking, and see a static “beginning” for a new software project. Despite that, I believe they’re simply trying to describe the agile practice of using tests to guide software development. We start every new feature by asking why we want to build it, and then how we plan to test it. We test the new ideas! We draw prototypes on a whiteboard and “test” those. We ask customers (or potential customers) to test our ideas. We use learning releases to see if our feature ideas are really worth a big investment.
The practice of test-driven development, which helps developers design maintainable, correct code, is well established. Many teams are using business-facing tests to guide development, practicing techniques such as behavior-driven development (BDD). Exploratory testing often begins even before a code change is committed to the source code control. We test-drive quality attributes such as performance, security and accessibility - we don’t wait until the release candidate is delivered. Testing isn’t a phase, it’s an intrinsic part of development.
By “shift right”, people mean that they aren’t going to just throw the feature over the wall to ops when it deploys, they’re going to monitor, observe, analyze log data, and “test in production.” DevOps drew our attention to the need to keep testing even when the new changes are deployed to production. We can use feature toggles and other means to manage our changes until we’re satisfied they’re working correctly in production. As we learn from data about production use, we use that feedback to guide subsequent changes.
The concept behind “shift left” and “shift right” is excellent and is the focus of the agile and DevOps approaches. But modern software development is no longer a linear process, so what does shift left and shift right actually mean?
There’s No Beginning, There’ll Be No End (Hopefully!)
Shifting towards the “beginning/left” or the “end/right” of software delivery doesn’t make sense for a team using agile and DevOps principles and practices to deliver value to customers frequently, at a sustainable pace. Modern software development is an infinite loop of developing small chunks of features, getting feedback as they are used in production (perhaps by a small number of people), and continuing to add, remove, and change them based on what we learn from the feedback. Ellen Gottesdiener and Mary Gorman, in their book Discover to Deliver, represent this process with an infinity symbol:
Software testing plays a major part on both sides of this building and learning loop.
Because today’s software development is continual, we now talk about “continuous testing”, especially in the contexts of agile development and DevTestOps. In his post “Continuous Testing in DevOps”, Dan Ashby illustrated how testing fits into every part of DevOps in its continuous journey from planning and building to releasing and monitoring:
Illustration from “Continuous testing in DevOps”, Dan Ashby, https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
When we say “shift left” today, we’re really referring to the left loop of the infinite loop of software development and delivery. And when we “shift right”, we’re engaging in that right-hand loop. This is how I like to picture shifting left and right, in the context of testing. Rather than focusing our testing on the time when a release candidate is built and delivered, we widen our scope left and right.
Test Early, Test Often, Test in Production
Shift left and shift right testing consists of a set of varied activities that are woven into the learning loops of software development. We rely on feedback from testing to shape our features, to make sure new changes don’t cause unexpected outcomes, to make sure what we delivered is being used as expected by our customers.
As Janet Gregory has noted, using the term “shift left” could draw some people back to the big up-front analysis and requirements phases of waterfall. She proposes we use the terms “testing continuously” or “holistic testing”. I like those, because they encompass the whole infinite loop of discovering and developing, delivering and DevOps. Regardless of what your team chooses to call this phenomenon, the important thing is to look for ways to integrate testing into every development and operations activity your team performs.
Want to see how mabl can help you test early, and test often? Start your free trial today!
References:
“Shift Left - Why I Don’t Like the Term”, Janet Gregory, https://janetgregory.ca/shift-left-why-i-dont-like-the-term/
“Continuous testing in DevOps”, Dan Ashby, https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
Discover to Deliver: Agile Product Planning and Analysis, Ellen Gottesdiener and Mary Gorman, https://www.discovertodeliver.com
“The Learning Release”, Ardita Karaj, https://medium.com/@Ardita_K/the-learning-release-70374d2450b3
“Are we shifting left or in a continuous loop?” Augusto Evangelisti, https://mysoftwarequality.wordpress.com/2018/04/28/are-we-shifting-left-or-in-a-continuous-loop/
