Shift-Left: A Developer's Pipe(line) Dream?

This is an article from DZone's 2023 DevOps Trend Report.

For more:

Read the Report

The software development life cycle (SLDC) is broken. In fact, the implementation steps were flawed before the first project ever utilized Winston Royce's implementation steps. 

Figure 1: Winston Royce software implementation steps (Waterfall Model)

Dr. Winston Royce stated "the implementation described above is risky and invites failure" in the same lecture notes that presented this very illustration back in 1970. Unfortunately, that same flaw has carried over into the iterative development frameworks (like Agile) too. 

What is broken centers around when and how the quality validation aspect is handled. In Figure 1, this work was assumed to be handled in the testing phase of the cycle. The quality team basically sat idle (from a project perspective) until all the prior work was completed. Then, the same team had a mountain of source code which had to be tested and validated — putting the initiative in a position where it is difficult to succeed without any issues. 

If it were possible to extract a top 10 list of lessons learned over the past 50+ years in software development, I am certain that the consequence of placing quality validation late in the development lifecycle is at the top of the list. This unfortunate circumstance has had a drastic impact on customer satisfaction — not to mention livelihood of products, services, or entire business entities. 

Clearly, we are far past due for a "shift" in direction. 

How Shift Left Is a Game Changer

Shift left is an approach that moves — and really scatters — the testing phase of the development lifecycle to earlier in the process. In fact, the "test early and often" approach was first mentioned by Larry Smith back in a 2001 Dr. Dobb's Journal post. To demonstrate how shift left is a game changer, consider the basic DevOps toolchain shown in Figure 2, which has become quite popular today: 

Figure 2: DevOps toolchain

Shift left adoption introduces a testing effort at every phase of the lifecycle, as is demonstrated in Figure 3: 

Figure 3: DevOps toolchain with shift-left adoption

Employing a shift-left approach redistributes when the quality aspects are introduced into the lifecycle: 

• Plan – Expose fundamental flaws sooner by leveraging and validating specifications like OpenAPI.
• Create – Establish unit and integration tests before the first PR is created.
• Verify – Include regression and performance/load tests before the first consumer access is granted.
• Package and so on – Assure the CI/CD pipelines perform automated test execution as part of the lifecycle. This includes end-to-end and sanity tests designed to validate changes introduced in the latter phases of the flow.

As a result, shift left yields the following benefits: 

• Defects in requirements, architecture, and design are caught near inception — saving unnecessary work.
• Difficulty in trying to comprehend and organize a wide scope of use cases to validate is avoided by the "test early and often" approach inherent within shift left.
• Understand performance expectations and realities, which could potentially drive design changes.  
• Determine breaking points in the solution — before the first production request is made.
• Avoid having to make design updates late in the lifecycle, which is often associated with unplanned costs.  
• Higher staff levels required to fully test at the end of development are avoided by dedicating smaller staff levels to participate throughout the development lifecycle.

Shift Left in Action 

The "test early and often" approach often associated with shift left has the direct result of better quality for a given solution. Here are a few key points to expect when shift left is put into action.

New Career Path for Quality Engineers

One might expect the pure focus of shift left to be on quality engineers assigned to the initiative. That is not really the case. Instead, this change becomes the role of every engineer associated with the project. In fact, more organizations today are merging tasks commonly associated with quality engineers and assigning them to software engineers or DevOps engineers. Forward-looking quality engineers should evaluate which of these engineering roles best suits their short- and long-term goals when thinking about their role in shift left-driven organizations. 

Test Coverage

In a "test early and often" approach, actual tests themselves are vital to the process. The important aspect is that the tests are functional — meaning they are written in some type of program code and not executed manually by a human. Some examples of functional tests that can adhere to shift left compliance are noted below: 

• API tests created as a result of an API-first design approach or similar design pattern
• Unit tests introduced to validate isolated and focused segments of code
• Integration tests added to confirm interactions across different components or services
• Regression tests written to fully exercise the solution and catch any missed integrations
• Performance tests designed to determine how the solution will perform and establish benchmarks

The more test coverage that exists, the better the solution will be. As a rule of thumb, API and unit tests should strive for 100% code coverage and the remaining tests should strive for 90% coverage since reaching full coverage is often not worth the additional costs required. 

Pipeline Configuration

Adoption of the shift-left approach can require updates to the pipeline configuration as well. In addition to making sure the tests established above are part of the pipeline, sanity and end-to-end functional tests should be included. These sanity tests are often short-running tests to validate that each entry point into the solution is functioning as expected. The end-to-end functional tests are expected to handle the behavioral aspects of the application — validating that all of the core use cases of the solution are being exercised and completed within the expected benchmarks.

Release Confidence

The end result of shift left in action is a high degree of confidence that the release will be delivered successfully — minimizing the potential for unexpected bugs or missed requirements to be caught by the customer. This is a stark contrast to prior philosophies that grouped all the testing at the end of the lifecycle — with a hope that everything was considered, tested, and validated. 

Too Idealistic?

Like any lifecycle or framework, there are some key challenges that must be addressed and accepted before shift left is adopted into an organization to avoid a "too idealistic" conclusion. 

Must Be a Top-Down Decision

Shift left must be a top-down decision because the core philosophy changes that are being introduced extend beyond the team participating in the initiative. What this means is that managers of quality engineering staff will find themselves dedicating individuals to projects on a long-term basis instead of handling all the validation efforts after development has been completed. From a bigger-picture perspective, those quality engineers are likely going to find themselves adapting their role to become a software or DevOps engineer — reporting to a different management structure.

Level-Set Expectations

The shift left approach will also require expectations to be established and clarified early on. This builds upon the last challenge because each step of the lifecycle will likely require more time to complete. However, the overall time to complete the project should remain the same as the projects that achieve full and successful testing at the end of the lifecycle. 

It is vital to remember that defects found by shift left adoption will have less of an impact to resolve. This is because the testing is completed within a given phase, reducing the potential to address additional concerns that must be resolved in prior phases of the lifecycle.

Sacrificing Quality Is No Longer an Option

A risky approach often employed for initiatives that are pressured to meet an imposed deadline is to shorten the amount of time reserved for the quality and validation phase of the lifecycle. When shift left is adopted, this is no longer a valid option since a dedicated testing phase no longer exists. While this approach is never something that should be considered, aggressive decision-makers often would roll the dice and sacrifice the amount of time given to quality engineers to validate the initiative, hoping for a positive result. 

Conclusion

Throughout my life, I have always been a fan of the blockbuster movies. You know those movies made with a large budget and a cast that includes a few popular actors. I was thinking about the 1992 Disney movie Aladdin, which builds upon a Middle Eastern folktale and features the comic genius of the late Robin Williams. I remember there being a scene where the genie gives Aladdin some information about the magical lamp. Immediately, the inspired main character races off before the genie can provide everything Aladdin really needs to know. It turns out to be a costly mistake.

I feel like Dr. Winston Royce was the genie while the rest of us raced through the lifecycle without a desire to hear the rest of the story, like Aladdin. Decades and significant cost/time expenditures later, a new mindset has finally emerged which builds upon Royce's original thoughts. 

Regardless of your team's solution destiny, shift left should be strongly considered because this is something we should have been doing all along. Taking this approach provides the positive side effect of transforming dedicated quality engineers to software engineers who can participate at every step of the lifecycle being utilized. The biggest benefit is identifying defects earlier in the lifecycle, which should always translate into a significant cost savings when compared to finding and fixing defects later in the lifecycle. 

To succeed, implementing shift left must be a top-down decision — driven by an organization-wide change in mindset and supported by everyone. Not ever should a reduction in quality or performance testing be a consideration to shorten the time required to release a new feature, service, or framework. 

Have a really great day!

References:

• "Shift Left," Devopedia
• "Successfully Implementing TDD/BDD to Enable Shift-Left Testing Approach" by Pavan Rayaprolu 
• "Managing the Development of Large Software Systems" by Dr. Winston W. Royce 
• "Shift-Left Testing" by Larry Smith  

This is an article from DZone's 2023 DevOps Trend Report.

For more:

Read the Report