Sequential development processes can no longer sustain the demand for fast and frequent software releases. Waiting to run performance tests and vulnerability scans until before production doesn’t cut it. Developers and testers need to work together to incorporate testing practices every step of the way.
In this article, we break down the concept of shift left and the importance of integrating testing from the beginning of the development cycle. We also recommend ways to encourage its adoption in your teams’ workflows.
The need for shift left testing
Traditional software development workflows are based on the waterfall model. The process is sequential, in that the execution of each step depends on the completion of the previous one. In this model, testing is usually done right before the release. This poses several problems:
When services are developed early and tested toward the end, any bugs will only come to light before you push them to production. Fixing these errors becomes a tedious and costly affair when your developers can only do so retroactively.
Testing does not always begin and end with one test. It introduces the possibility of having to debug and retest. With little time to debug in pre-production, you run the risk of delaying or rushing deployment. Either situation is suboptimal as it creates an atmosphere of urgency, putting developers and SREs under significant pressure.
You will have dips in team morale if these situations frequently arise at the point of production.
If rushed, the quality of the code may suffer. There is also more room for oversight in the case of testing and running security scans.
In today’s environment, when frequent releases are the default, waiting to test delays and lengthens the workflow.
Shift left emerged in response to the insufficiencies of the waterfall model. It integrates quality assurance (QA) and development processes to encourage early testing and debugging.
Understanding shift left
Shift left testing emphasizes the need for testing from the first stages of developing a service or architecture for your application. These tasks are usually relegated to the end of the process. However, instead of only running automated performance tests and vulnerability scans during pre-production or deployment, a shift left strategy implements these at the time of development or earlier. These are tangible processes that you can start incorporating early to avoid catching performance issues in production.
It’s worth noting that the tests are not entirely moved to the start but are instead spread across the life cycle of the software to promote continuous feedback and recovery.
In large organizations, developers write their code and send it to testers or the security team only when they are finished. After running the scans independently, the testers share errors and bugs they have identified for the development team to fix. Shift left aims to do away with this inefficient back-and-forth to replace it with a collaborative workflow from the outset. Developers and testers work together to test small chunks of code as part of the development process. Working together encourages developers to consider functionality and security more seriously when writing code.
Shift left is different from shift right in that the latter is concerned with continuing to test even in production. It stresses that security is an ongoing process. Shift right focuses on the finishing touches of the software to ensure that it performs well when faced with traffic. It also helps you further improve application quality.
Types of shift left testing
Donald Firesmith uses the V-model to classify shift left testing methods under the following four types. Each of these types builds on the former, with model-based testing slowly being accepted as a viable method.
Traditional shift left testing
Traditional shift left testing calls for foregrounding unit and integration tests during development. They scan your microservices and ensure that they are running as expected. Although subsequent acceptance and systems testing is not to be neglected, only when your teams are confident in foundational functionality can the whole architecture come together.
Incremental shift left testing
Teams working on larger, more complex architectures tend to divide the project into smaller increments to work on. These are tackled one at a time as each builds upon the previous sections. Consequently, the testing processes also shift left in that they are performed for each increment before beginning work on the next one.
For example, unit and integration tests are run in two sections. A third section is added as an increment. It is easier to identify errors during the tests run at this stage, as opposed to when you are doing integration testing among all the services towards the end. If an increment is to be released to users, both development and operational testing are executed at this point.
Agile or DevOps shift left testing
An agile workflow is characterized by sprints. These are pre-defined time periods during which a development team works on a set of goals. A project usually contains numerous sprints executed one after the other. In this case, shifting left means testing as part of each sprint. This is easier to achieve as sprint results are usually shared with stakeholders or pushed to production. Shift left testing supports the continuous deployment strategy of agile workflows and is primarily concerned with development testing.
Model-based shift left testing
Model-based testing goes one step further to identify errors and vulnerabilities before the code is even written. The other three types begin at the start of the development process. Here, tests are written in advance to be run when executable requirements are outlined and the software is designed. This allows for bugs to be eliminated before the developers put time and energy into coding. Testers, too, need not wait long to execute scans.
Model-based testing is evidence that shift left can be part of various test stages, including design and security. Security testing for your microservices architecture is non-negotiable. Performing it continuously and right from the beginning will ensure that your software performs well on security and reliability metrics.
Benefits of shifting left
Shifting left directs your attention and efforts toward preventing problems, rather than merely detecting them. These are a few benefits of making the switch:
Bugs are most likely to be introduced in the development phase, at the time of writing code. Traditionally, these are brought to light only before production, leaving little time for resolution. As a result, bugs are often only patched and costlier to fix. This is not ideal if you want to build or expand on this code in the future. Shifting left takes care of this problem so that your development team has enough time to properly resolve the errors.
Including testers, SREs, and security teams in the initial planning stages allows them to communicate guidelines and access the resources that they need.
Shifting left before the development phase highlights issues in the design and requirements. Rectifying these at the beginning itself results in fewer bugs subsequently. The few that remain may also be easier to deal with. You can avoid the trap of postponing tests and bug fixes and adopt the practice of fixing them as and when they surface.
Testing across these stages also culminates in higher-quality software. It is not riddled with patches, and the team can focus efforts on monitoring and observability.
It is both time and cost-efficient. Testing and security teams are not forced to wait over extended periods. They can work with developers and focus more energy on other tasks that need their attention.
Testing at every stage also increases test coverage. You do not have to worry about missing certain functionalities.
Last-minute functionality and security issues are avoided, making for smoother rollouts for both the teams and end-users. Your releases are not only faster but also of better quality.
Identifying problems early also saves the cost and effort it takes to undo them at a later stage. They don’t have the opportunity to turn into complex and high-risk errors.
In addition to the actual processes that comprise shift left, it is important to recognize that getting your teams to adapt to a culture overhaul can be a challenging process.
Shifting left is about culture
Switching to shift left necessitates a change in your teams’ workflows. This is especially important in larger organizations. You need to consider how you can get developers to care about reliability and performance testing in the earlier stages. They should be running vulnerability scans and thinking about security as part of the design and review process, as opposed to the security team doing these independently and returning with a list of issues for the developers to resolve.
Quality Assurance (QA) teams played this role a few years ago, but the shift left mentality emphasizes a more collaborative workflow that encourages developers to do testing as part of development. It is no longer a common practice for developers to run some code and ship it off to external teams to bear the burden of testing. With an increase in the adoption of shift left testing, we expect more avenues for teams to communicate and build software together.
Testing, reliability, and security teams cannot completely rid themselves of these responsibilities. They must work to set in place systems and expectations that foster higher developer engagement in testing processes. After establishing expectations, they can assign small testing tasks to developers as part of their development workflow. These give developers the confidence that they are going about it correctly and meeting expectations.
Testers can offer basic training and tools for developers to adjust to the new process, including writing better programs and running basic unit tests. This offers testers and SREs the opportunity to redirect their time and energy to running business analytics and test performance in production.
Switching to shift left is not an overnight process, but it is something that offers high returns as and when your teams adapt to it. The decline in risks and increased reliability and safety are rewarding for your team and users alike.
Shift left testing best practices
Although introducing shift left testing to your team can be a laborious process, it can be made easier by starting slow and adopting a few best practices. Some of these include:
Test-driven development (TDD): This approach emphasizes writing tests for your functionalities before you begin writing the code. At the moment of development, then, it will suffice to merely run them and glean any discrepancies or vulnerabilities for quicker fixing and recovery before moving on to the next step in development.
Test automation: Shift left is amenable to automating tests to save time and effort better utilized elsewhere. It prevents overburdening your developers, testers, and security teams and provides faster feedback. There is less likelihood of human error, which can be a considerable obstacle in running effective tests.
Coding standards: Establishing best practices and standards for coders, including testing and security considerations, can go a long way toward integrating and normalizing them as part of the workflow. It also does away with any discrepancies. It is easier for teams to collaborate when everyone is on the same page.
Implementation decisions: Decide which methods work best for your teams so that you can implement shift left from an early stage. You may choose to adopt an agile workflow or decide that unit and integration tests must be run at certain intervals.
Service virtualization: You can have provisions for service virtualization so that developers can run tests with minimal dependency i.e., even in the absence of certain components or services.
Getting started
Setting up shift left testing for your microservices architecture is a reliable way of accelerating your processes and improving the quality of your software. Cortex’s scorecard lets testing, security, and SRE teams define best practices for testing in development. This is hugely beneficial to developers who will then understand and meet expectations.
