‘Shift left’ as a term used in software testing refers to the process of integrating testing into earlier stages of the development process compared to traditional testing methodologies. In classic development methodologies such as agile, each sprint represents a linear process from design and development to testing and release. Testing is classically an end-stage process that can be thought of on a linear horizontal scale as happening somewhere on the right side near the end, conducted once all development work has been completed. However, shifting left and introducing testing earlier in the process brings a number of advantages that will be explored in this article.
Advantages of Shifting Testing Left
Traditional software development processes, such as those used in agile environments, treat testing as a discrete process separate from development. Testing is conducted somewhere after development has begun. Typically, this is after the bulk of development has been completed. However, there are a number of problems with this approach.
Probably one of the most obvious problems of leaving testing as an end-stage process is that it prevents bugs and software defects from being identified and fixed sooner. Mistakes can be very costly, especially if issues are not caught until code has already been pushed to production. Finding a bug at the last minute is also problematic for its own reasons – depending on the severity of the bug, it could result in costly, chaotic deployment delays and missed deadlines. Rushed test processes due to tight deadlines or schedule overrun by developers can also result in missing bugs or defects before they hit production.
Catching bugs and defects as soon as possible should be a goal of any testing team, for numerous reasons. One is to identify software defects as soon as possible in order to prevent the propagation of a flawed component or design choice. Another is to get feedback to developers in as timely a fashion as possible. Shortening this feedback loop as much as possible can be hugely beneficial, as developers who are not in the same headspace as they were when they wrote the defective code will have to take additional time to once again comprehend the code in order to fix it. The time saved by shortening this gap can cumulatively represent hours that developers would otherwise spend refamiliarizing themselves with a problem before being able to fix it.
At the other end of the spectrum lie development methodologies like test-driven development (TDD). TDD has developers write tests as the very first thing they do before actually writing code that passes those tests. There are some problems with this approach as well, however. It’s not a very efficient development method, as not all problems can realistically be conceived of ahead of time. It’s also difficult to determine how much value each individual test provides. TDD is ideally suited to unit testing, but in E2E testing it often results in bloated test suites that take a long time to run (further slowing deployments and developer velocity). Clearly, there is a sweet spot as to when testing is most appropriately introduced into the software development process.
How to Shift Left
Shift left testing is a testing methodology as much as it is a technical process and it requires buy-in from both testers and developers. Developers must be willing to work closely with testers in order for tests to be created, run and maintained during the development process. This means bringing teams to work together that may have previously been siloed and had little interaction with each other. Shifting testing left is an iterative process that can be achieved incrementally. Both teams should take ownership of the tools and procedures used as part of the deployment process. By promoting a shared responsibility for the deployment process, it becomes in the best interest of all involved that both development and deployment are well-tested, rather than one team wiping their hands of responsibility once ‘their part’ is done.
All teams should be working in similar environments, which should match the production environment as closely as possible. Until relatively recently, this was quite difficult to do, as few teams could afford to match production specs in their test or development environments. However, with the rise of virtualization and cloud hosting, this has become much more feasible. Differences in environment configurations between teams can be a very subtle source of bugs that is difficult to detect, so making sure all teams work in the same environment can reduce or outright eliminate this as a potential source of issues. This too requires teams working together in order to define and agree upon a particular environment configuration and for all teams to be involved in the provisioning process.
The focus of shift left testing should also shift testing priority from bug detection to bug prevention. By having teams work closer together, testing and deployment processes can be unified that may otherwise be completely different between testing and development teams. If the development team runs a few tests manually and understands that the testing team has a fully automated testing suite that they use, they may be less inclined to put in effort into catching bugs on their end. The development team might believe the testing team will simply catch bugs and issues that they miss for them. By uniting teams and pushing for testing earlier and more frequently, everyone feels more of a shared responsibility for defects. There is also more time and opportunity available to find and fix these bugs and defects.
How Shift Left Empowers Automation
Shifting testing left is not as simple as executing your test suite during the development process. Although it can work, overlapping software development and manual testing can be difficult to get right. Tests need to be quick to run and quick to deliver feedback; otherwise, software development may either outpace testing and result in redundant tests, or end up roadblocked awaiting testing results.
Shifting testing left works best with automated testing processes, such as continuous testing. In continuous integration/continuous development (CI/CD) environments, teams regularly commit new code to repositories on a regular basis, typically daily or even hourly. This code is usually integrated into the production codebase as soon as it passes testing. Continuous testing is an extension of CI/CD, whereby tests are run against each commit to a repository. This approach fits in well with a shift left approach to testing, as once a continuous testing pipeline has been established, tests can be automatically run against commits large and small at almost any stage of development.
Shift Left and DevOps
As mentioned earlier, a shift left approach to testing requires buy-in from both developers and testers, as both teams must work closer together on a more frequent basis in order to integrate and run testing during the development process. DevOps brings disparate teams closer together in order to meet these needs and further shorten software development life cycles. Segregated teams may suffer from poor communication, mismatched work schedules and conflicting goals.
These are exactly the kind of issues that many teams are likely to face if teams choose to shift testing left without also considering the ramifications this will have on both developers and testers. Teams looking to shift left should also consider adopting DevOps best practices and tools to help smooth this transition and get teams working closer together. Common DevOps practices already marry well with shift left testing, such as automated testing and continuous delivery, so many of the best DevOps practices are well-suited to a shifting left in testing.
Adopt Shift Left Testing Principles to Reduce Failure
Shift left testing offers a number of benefits over treating testing as a discrete stage in the software development life cycle. By introducing testing earlier in the development process and conducting testing alongside development, teams are offered the opportunity to detect and fix bugs earlier in the development process. Teams also feel more of a shared responsibility for a project, as lines become blurred over which stage of a product a particular team is responsible for. Instead, both developers and testers are encouraged to find and fix defects as and when they arise.
Shift left testing is a team process as much as it is a technical process. While test automation and deployment are a part of a shift left approach to testing, it is also as much about bringing different teams together and having them work closer together on a project. Sharing responsibility rather than dividing it up and unifying tools, environments and processes all form part of the shift left approach to testing but can be difficult to implement if nobody has prior experience in doing so.
ProdPerfect’s approach to shifting testing left is to develop automated tests autonomously, and prioritize those tests using data, so test suites are lean and effective, and constantly updated. For tech leaders interested in moving towards testing further left in their SDLC, ProdPerfect is an approach worth considering.