Pick up any article or watch any talk on a testing-related topic these days, and you’re bound to see the terms “shift left” and “shift right”. They’re almost a cliché. What do they really mean? Modern software development isn’t supposed to be linear anymore, right? There’s not one point where it starts and another point where it ends. It felt that way in waterfall days when we often worked on release cycles of a year or more.
And yet, so many teams – probably still the majority – are still in a place where a software development team works on a new change, builds a release candidate, and throws it over the wall to an operations team. The developers start working on the next new feature, and the operations and support teams (and, shudder, “maintenance” teams) take care of the production code. They might be deploying to production frequently, but the people building the software never feel customers’ pain caused by bugs, poor performance and outages. With management pushing for more features, they don’t have much incentive to build testability and operability into their software product.
Continuous everything
In my experience, successful teams adopt the “you build it, you run it” approach for their successful products promoted by the DevOps movement. I prefer to think of this as “we build it, we run it, we own it”. One delivery team, or for a larger organization, multiple delivery teams, help the business evaluate feature ideas and risks. They design the product and its architecture, making sure everyone in both business and development share the same understanding of what to build. They test feature ideas; they use examples, scenarios and executable tests to guide their way.
For each new feature set or epic, the identifies a thin slice, end-to-end “learning release” which they can get in front of customers quickly to get feedback. They guide development with tests at unit, API and UI levels. A variety of testing activities, such as exploratory testing, security testing and performance testing, may be started as individual stories are completed. As these teams work on the left side of the so-called DevOps loop, they instrument their code to capture log and event data so they can take good care of the product in production. They collaborate with platform or site reliability engineers (SREs) to set up the visualizations and alerts that will provide feedback.
Diverse teams collaborating FTW
Team members have different specialties, different deep skills tend to many aspects of quality as they work to solve customers’ problems one small change at a time. When they merge these changes to their source code repository trunk or master, they work together to shepherd them through their deployment pipelines. Together, they’ve designed these pipelines for fast feedback, using techniques like release feature toggles to enable continuous delivery while accommodating human-centric testing activities like user acceptance testing that may be part of the pipeline. They’ve also agreed on how to respond to pipeline stage failures.
While all this is going on, the team shares responsibility for keeping an eye on monitoring dashboards, responding to alerts, and helping with customers’ issues. They have occasional “game days” to practice responding to production failures and testing the procedures in their runbook. Their pager rotation list includes developers and testers on the team as well as the SREs. The whole team is just as engaged in the right side of the DevOps loop as they are on the left.
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
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 terms “shift left” and “shift right” 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.
The post Shifting left & right in our continuous world appeared first on Agile Testing with Lisa Crispin.
