Last year, “shift left” — the idea of automating and introducing a variety of activities earlier into the software build cycle — was one of the hottest topics in development. I have talked about it frequently, and I believe it is fundamentally important to ensuring the quality of software, making it faster and better.
Areas that can be shifted left include functional and non-functional testing, code reviews, security code analysis (static and dynamic), security validations, performance and UX assessments, and code coverage assessments.
However, recent research carried out with the Gatepoint 2020 State of Test Automation Report shows us that shift left has not been widely adopted, at least not yet. Also, while the report focused on testing, anecdotally I hear from various companies that they have yet to embrace shift left in other areas, too.
[ Read also: Security 2020: 4 trends to watch. ]
The report, spearheaded by Gatepoint and Perfecto, surveyed executives from over 100 leading digital enterprises in the United States on their testing habits, tools, and challenges. Of companies surveyed, 63 percent responded that they’re starting to test only after a new build and code is being developed.
The survey results show that only 19 percent use development teams for testing, as opposed to 81 percent that still depend on QA teams. Just 40 percent test upon each code change or at the start of a new software sprint, the survey states.
Why shift left matters in DevOps
It is not the answer to every software development challenge, but shifting left matters. It is more cost-effective to reveal and fix defects and other issues earlier than later. It also supports the ethos of “fail fast, fix fast,” which helps remove code instabilities and improve quality.
Additionally, shift left is a natural partner for continuous integration (CI) and the overall trend towards automation, which sits at the heart of DevOps and helps address the increasing complexity, scale, and speed of software releases. Pushing these activities left in the process also makes it easier to maintain them between future releases.
Let’s look at security as an example: Shifting security practices left means that DevOps teams are embedding into their software iterations lifecycle the full scope of security from the requirement phase, audits, quality, checkpoints within each release, and remediation of defects. So as code changes are checked in, the relevant security validations take place, and vulnerabilities are identified and fixed prior to release.
[ Read also: Why DevSecOps matters to IT leaders. ]
What goes wrong: Imposition, fear, and resentment
So why has shifting left not taken off as many people expected? Much of the challenge — as usual — comes down to corporate culture: It must start with leadership support.
If software development teams are incentivized purely by meeting deadlines, there is a risk that testing — and in its wake, bugs and security issues — becomes secondary. This is, of course, a false economy: We all know what the fallout can be from product failure, cyberattacks, and dissatisfied customers. Elevating shift left to a business-class requirement is essential.
There may also be fear and resentment around the idea of shifting left. Asking an already busy software development team to take on yet more work probably will not go down well. While shifting left takes work off colleagues later in the build cycle, it is important to not just transfer that effort to overworked developers and to find ways to test shifting left without increasing anyone’s workload.
Using tools that automate or streamline shift-left initiatives is part of the answer, but history shows us that if developers do not want to use a tool, they will find a workaround. That’s why it is vital to involve teams in the tool selection, or — through integration and open architectures — to introduce ways to shift left that do not impose on their workflows and preferred toolsets.
Another barrier happens when product owners fail to engage with the people responsible for early stages of software development at the beginning of a project. Again, this is usually a cultural issue.
How to overcome the challenges: 6 tips
So, how can we overcome these challenges? Here are a few suggestions on how to improve shift left adoption:
Educate everyone about the business value of shifting left. That includes product managers, managers, and developers. Involve teams in choosing tools from the start.
Have a clear definition of the scope of areas, such as testing. If it is too large, then it cannot be integrated into the build cycle to shift left. Break it down into chunks, such as essential functional testing scenarios, unit testing that is specific to what was changed, security, performance, and other non-functional testing. Review test suites regularly to make sure they stay relevant.
Make it easier. Choose techniques and tools that fit around existing workflows, integrate with preferred tools, and automate as much as possible (while understanding that not every test can be automated). Consider codeless tools and other methods that make the shift-left concept more accessible.
Exploit smart analytics. Use intelligent data that can be gathered through tools designed for shift left. These will help you sift through all the noise and better understand what has real impact on the business so you can make more informed decisions. This, in turn, will help the wider team understand the benefits of shifting left as well as the tangible value of that process to the business throughout the SDLC.
Know what can’t shift left. There are a few prerelease activities, such as final exploratory and UX manual testing, that need to happen closer to production. Things that happen only rarely can be performed outside the build cycle so that the team can focus on activities that benefit most from shift left.
Understand the bigger picture. In the context of Agile and DevOps, organizations are looking at shift left with a wider lens and are even adding the shift-right concept, such as testing continually into production to enable an ongoing feedback loop with developers upon each release.
The more teams can shift left – and shift right – the more confident they can be that they are producing high-quality software at speed and at scale. This wider view supports the central tenets of successful DevOps and Agile: continuous inspection, continuous improvement and delivery, automation wherever possible, and overcoming time-to-market roadblocks while still ensuring high-performing, secure, and relevant software.
[ How do containers help manage risk? Get the whitepaper: Ten Layers of Container Security. ]
