Everything you need to know about shift left [DevSecOps]

Published May 31, 2017

In every organization, maintaining quality and testing at the same time is a challenge. This is especially true as new features and updates are being developed. This kind of work needs to be done continuously in order to guarantee that the new update won’t knock out the entire system. When testing is being started earlier, there’s more time to focus on quality and have a “do it right from the beginning” mentality. In turn, this saves time and decreases the number of iterations required to make changes and improvements. This is what’s called shift left. <h2>Shift left</h2> The premise behind shift left is to move up things normally done later in the development cycle. Many tough problem are often being postponed, only to become bigger problems in the future. In the end, this leads to a significantly worse situation when the problems needs to be addressed. Within the shift left methodology, you fix these problems earlier (sometimes even before they occur). The term shift left also refers to a <a href="https://smartbear.com/learn/automated-testing/shifting-left-in-testing/">method of software development</a> in which the team earlier focuses on quality and works preemptively with addressing problems. It also includes testing much earlier. With this, you strive to increase quality, shorten test cycles and reduce the risk of unwanted surprises in the end of the development cycle – or even worse, in production. <h2>DevOps and testing</h2> Using this way of thinking we can also find two parts of <a href="http://solidify.se/why-devops-is-a-necessity-for-software-development/">DevOps</a> to utilize: continuous testing and <a href="http://solidify.se/continuous-delivery-integration/">continuous deployment</a>. It’s about creating and running automated tests as soon as as often as possible. Such testing, together with continuous updates, creates an environment in which the development team can focus on quality early. By involving testing earlier you hope to identify potential issues earlier in the development cycle. If you manage to do so, there’s also more time to address these. All in all, when errors and bugs are found earlier, less time is required to fix a erroneous implementation. Since bug handling also becomes tougher as the application grows in complexity, you can save time there as well. With shift left, you can save time, money and a lost of frustration. <h2>Summary</h2> To summarize, there are multiple advantages of the shift left methodology: <ul> <li>Improved design: With continuous testing comes more opportunities to address upcoming problems, bottlenecks and other areas of improvement. This opens up for new design options building on the original idea, but with less issues.</li> <li>Early bug handling: When we stop and trhink about how many times a bug could have been handled much easier when it was first discovered, we quickly see the value of shift left. It creates breathing room and allow us time to manage our mistakes right as they happen.</li> <li>Time and money saving: When you talk about improvements in efficiency and quality, it would be strange not to talk about time and money savings. With shift left, you save both time and money.</li> </ul> The essence of shift left is, in many cases, an illustration of the classic test early and often.   Have you started working with shifting left? Did we miss out on any pros or cons? Let us know in the comments below!