If you have any involvement in testing or DevOps we hear a bunch about Shift-Left and Shift-Right. The idea is that we bring testing earlier in the development of the product and that we continue to test after the product is released. But what if there’s a third dimension, one that helps us make sure we are testing where most effective and needed, along with making the most of our testing resources? Jon Bach wants us to consider "Shifting Out" along with the familiar options.
Think of Shifting Out less as a directional movement and more of an elevation movement (rise up or levitate might be better words but it's not as memorable as Shift Out, so I get it :) If shift-Left deals with working with or around a particular tree, Shift Out gives you a view of the entire forest. Shifting out is all about your perspective, and along with that, balancing testing resources so that we have placed our attention on the important areas (harder to see when staring at one tree, so to speak ;) ). By logic, we can also consider Shifting In after we have Shifted Out.
Okay, so I get the general idea of Shift Out. How do we do it?
Customer bug reports are an interesting example. Who owns the issue? Where should testing be applied? When? Would Shift-Left or Shift-Right be helpful here? Does it even fall within the Left or Right framework? As we shift out, we start to see that problems don’t always fit neatly into one category—they often require collaboration across multiple teams to resolve.
Early bug detection is great but the fact is that we can’t always catch bugs early, no matter how much we Shift-Left. Incomplete requirements, unknown user behaviors, and system complexity introduce a lot of unknowns, meaning that some issues are not only unlikely to be found but may be impossible to find until the code goes live. Shifting out acknowledges this and encourages teams to plan for uncertainty rather than simply striving to eliminate it.
What signals are your tests sending? Meaning are your tests highlighting the right problems? What can you learn from the data generated across development, test, and production environments? It's not enough to just run the tests. We need to analyze what the tests are telling us and what data we are getting and analyzing. Additionally, it may make sense to reframe existing tests. This way, we get the information from our original tests but also get additional information by pivoting to a different aspect or need. Same test, with different results, and possibly different conclusions.
Shifting-Out (and Shifting-In) are all about zooming in and out to consider the broader context of our testing strategies. Shift-Left and Shift-Right help focus on specific aspects of the software lifecycle, shifting out lets us step back and see how the pieces fit together.
Shift OUT is about:
Outlook: getting credible action items and information
Understanding: knowing about the issues and contexts where they fit and what/why it matters
Treatment: knowing where and when the appropriate solution needs to be applied, as well as why it is the most effective
Ultimately, focusing solely on Shift-Left or Shift-Right leads to a tunnel vision effect. Shifting-Out helps with developing perspectives for managing all of the possible quality processes. Catching bugs earlier and learning from production is important. So is understanding the bigger picture and making informed decisions that help balance both.
No comments:
Post a Comment