A phrase we hear often in Software Testing circles and commentary is “shift left.” When we dig a little, we realize that “shift left” is talking about the idea that Software Testing is happening either too late in the process or it is not effective at the time it is being allocated. This dates back to an embrace, willingly or not, of the traditional Software Development Life Cycle (SDLC) and especially the Agile Waterfall (Agile Falls) methodology. In the waterfall methodology, each piece is completed (design, programming, testing, packaging, etc.) and the product moves through each of those cycles.
Where Does “Shift-Left” Come From?
For those of us who are used to looking at Scrum or Kanban boards, the idea is that projects move from left to right on the board. The left reflects the earlier efforts and processes, and the right reflects the later processes. Often, testing comes at the very end of these processes and the testing efforts, regardless of how much time is placed on them, is seen as “too little, too late.” Whether that is a fair statement, there has long been a feeling and a push to have elements of Software Testing happen earlier in the SDLC. This is in part what has led to the development of The Agile Manifesto. A key result of the Manifesto is the sense that testing should be fundamental to software development and that it should occur not after programming but during development and to happen continuously throughout the process.
This is the origin of the term “shift left.” Why did this come into being?
Simply put, in the organizations I have worked at, the drum beat of “shift left” has always come from one pain point. There is never enough time to do exhaustive and detailed Software Testing for products and projects that are programmed first and tested later.
We are used to the idea that you have to make a prototype of something first, and then test that prototype to see if it does what we want it to do. How can you “shift left” in that situation? Part of the problem lies in a limited view of what testing does. Testing is not only the literal “If I connect Terminal A and Terminal B with a power source, will the light in between them turn on?” That is fundamental to testing, of course, but there are many places where we absolutely can do testing earlier.
Shift Farthest Left – Initial Design and Proposal
One of the places Testers should be, I feel, is in the initial story workshops or planning meeting for future development. If this is the point where functionality is first being discussed, then this is as far left realistically we can shift. How, you might ask? Our first testing can occur here because our first hypotheses appear in this earliest of planning meetings. I credit this phrase to Jonathan Bach; this is the time to “provoke the requirements.” Too often, we think that we need to have everything built and in place for us to do actual testing. Instead, we can work to include Testers (or people with testing backgrounds and an understanding of testing) in these meetings. A great resource is also the test plan. Test plans are “the vehicle for communication”—described by LogiGear’s Michael Hackett. To learn more about how test plans can be used in a modern SDLC like DevOps, read his book Modern Test Plans. I have had the advantage of working in environments where this approach has been embraced. The benefit is that by my being there and discussing issues of Software Testing and feasibility, we are able to make considerations that are often more difficult later on in the process.
Making a Product “Testable”?
One of the biggest issues that is better handled earlier than later is the part about “testability,” literally how we intend to test that product. This is a discussion that often has 2 parts.
- The first is, “How do we test this in the here and now?”
- The second part of this process is, “How might we make this testing as repeatable as possible?” Is this a call to Automation?
In part, yes, but it is also a call to good science. Testing is at its root a core tenant of well done scientific experiments and I am a firm believer in keeping that paradigm front and center. In the design phase of a project, we can actively flesh out what our hypotheses are and with those hypotheses we can create experiments to confirm or refute them. This is the core of “provoking the requirements” but additionally this also allows me to ask more questions about how we might accomplish testing goals. If I do not get the chance to participate in this design process, it’s possible that testability hooks or ways that we could determine how to interact with a product may be made more difficult than they need to be.
As an example, I recall an accessibility project that I was working on where I was asked to participate in the testing process later on in software development. Specifically, I was asked to test after all development had been finished. During this process, it became clear that many of the typical approaches for accessibility had not been considered and I came back with a number of significant issues that they would then have to go back and fix. The challenge was that many of these areas would require a considerable amount of time to remedy. By contrast, had I (or another Tester) been involved in that initial design conversation, we could have suggested things they need to be aware of early and up front, so that the design wouldn’t have to be modified as extensively.
So, Where Does “Shift-Right” Fit In?
If we are talking about a typical software development project, we really don’t want to think of “shifting right” as delaying testing. Instead, what we want to think about is “What do we do after the feature we tested is pushed?” This could be a literal testing in production scenario or it could involve a staged approach. Most of the testing I perform is in development environments that have been optimized for my benefit and to let me do certain things to make testing efficient and effective. However, our customer environments are never the clean and pristine environments that we do our testing on. In reality, production environments are what I like to call “dirty systems”—and that’s not a disparagement. When I say a system is “dirty,” I mean that it has all of the other aspects a machine needs to run, including fallible human users who don’t always behave flawlessly and do things that are at times unusual and unexpected. Thus, it makes sense to keep testing and looking at how our software works after it has been deployed. Yes, my software is being tested all the time after it’s released, only our users are now doing the testing, whether they signed up for it or not.
A great example of shift-right testing would be an A/B test. If we have a feature we wish to deploy, we push it out to a handful of users, while reserving a number of users to not have the update. Then, we monitor and observe what happens. As we gather data, we can determine if the feature we have released works as we intend it to and also to see the reaction and adoption of that feature with the A/B test.
Do Testers Have To Be Involved?
This is the “elephant in the room” in a lot of organizations. Testing needs to happen but there is no law that says specifically Testers have to be the ones doing that work; for more on trends on how other roles, like Developers, are taking over testing tasks read this 2-part article by LogiGear’s Michael Hackett on Developer Testing? What is Testing and QA’s Place? Part 1 and Part 2. Having said that, I do believe and have past experiences that show me that dedicated Testers can absolutely be effective and beneficial to be part of those earlier discussions, and can also be effective in the post-production monitoring and information gathering. Testers are specifically focused on running repeatable experiments and making sure that their methodology works. These skills can absolutely be taught to others and the more people come to software development with a “Science Experimenter” mindset, the better. This will encourage more testing and thus the need for more active Testers, whether that be their formal job title or not.
Conclusion
As I stated earlier, when we describe shifting left or shifting right, we are using metaphors based on a literal project board, where there is a literal start and end point. The truth is, when we look at modern software development, there really is no beginning or end any longer, especially when we discuss platforms that are online and accessible as Software-as-a-Service (SaaS). These are updated frequently, in many cases multiple times a day, so the need for testing is ongoing and continuous. Shift-left and shift-right aren’t specific commitments beyond the idea that there should be testing all the time and in every capacity. Identifying those areas and then applying testing principles to them are what is needed. Once we do that, then we can get away from the idea that testing is an end goal, done just before a product releases, and all of the baggage that comes with that.
Michael is a Black Belt in the Miagi-Do School of Software Testing, helped start and facilitate the Americas chapter of Weekend Testing, is a former Chair of the Education Special Interest Group with the Association for Software Testing (AST), a lead instructor of the Black Box Software Testing courses through AST, and former Board Member and President of AST. Michael writes the TESTHEAD blog and can be found on Twitter at @mkltesthead. A list of books, articles, papers, and presentations can be seen at http://www.linkedin.com/in/mkltesthead.