In a competitive tech world, the pressure to stay on top of software releases is huge. You can't afford to slow them down.
Keeping on top of new trends, then, becomes important for the engineering leader to ensure you're staying ahead of the competition. When a new approach comes out of the woodwork and seems to be working for other teams, it's natural that tech professionals would want to know whether it will work for them.
That’s why, in chat channels across the world and during daily development team stand-ups, the question on everyone's lips seems to be, "Should we be using the shift-left approach?" What about shift-right?
The shift is on, to secure code. But there is no one right approach. Here's how your team can decide on how to secure your software development lifecycle (SDLC).
The traditional approach
Traditionally, developers favored the waterfall method. Created by Winston W. Royce in 1970, this approach is strict, linear, and sequential.
The software release process was completed in five stages: requirements gathering, design, implementation, verification, and maintenance.
The big problem with this method is that testing is often treated as an afterthought. Development teams collaborate with the customer, designs are created, and the product is built. Then testing happens.
As a result, testing is squeezed in when the team is tight on time and reaching the end of a project. It is, therefore, seen as a bottleneck; it's an awkward step to get through, where problems will inevitably arise. Testing is rushed or happens too late in your SDLC to locate critical bugs in time.
And when bugs are found, you feel as if they bring you right back to square one. Your product quality is unreliable as a result.
That's where the shift-left approach comes in.
What is shift-left?
Imagine your SDLC as a horizontal line. Now imagine where testing sits in it. Now take testing, and shift it left along the line. Move it closer to the beginning of the process.
That's what shift-left means.
By shifting left, testing can be introduced at the beginning of your SDLC. In teams that operate with the shift-left ideology, QA is involved in the requirements-gathering and design stages of the process.
Testers have input into what they believe will lead to bugs, or what features will require more rigorous testing. Then, testability is built into the code by methods such as test-driven development, where coders put testing at the forefront of their approach.
Shift-left, however, doesn't necessarily mean testing continuously. Although the continuous methodology is recognized by the software development community as a way to improve product quality, you can shift-left your testing without testing at every stage of your SDLC.
That's because shift-left, at its core, is more about a shift in the mindset of your team. A portion of your testing can still be conducted near the end of your SDLC, but the key difference is that QA has been considered from the very early stages. It's all about involving testers in the early conversations and designs that shape the product.
Putting quality front of mind means it is an ever-present factor in your SDLC. The common questions become "How does this impact quality?" and "How can we test this?" This will, undoubtedly, improve product quality.
What is shift-right?
Shifting left isn't an entirely new idea. In fact, programmers have recognized that testing early will produce better quality products since the 1950s.
What's more, it looks like the term shift-left has a competitor.
Shift-right focuses on the maintenance stage of your SDLC. Rather than simply handing the product over to ops, dusting off your hands, and forgetting all about it, development teams focus on testing in production, monitoring, and updating the software.
Shift-right doesn’t mean ignoring testing all the way to production, but rather recognizing and implementing a strategy that allows testing to occur even after a product is live and has a user base.
Which approach should you use?
There is no right answer here.
Thinking that you need to decide between shift-left and shift-right somewhat defeats the purpose of each approach. Both ideologies promote the idea that testing is not a static block in your SDLC.
Testing should not be considered a standalone stage in the process, and it certainly should not be treated as an afterthought. Traditional approaches such as waterfall can create an environment in which testing is seen as a bottleneck and a problem creator, rather than as a problem solver.
If you are repeatedly struggling with critical bugs and your product quality is suffering, it's worth reassessing how you structure your SDLC and whether a shift-left approach to testing could help.
Testing early doesn't just improve quality; it saves costs, too. A bug found in the early stages of the SDLC costs $25 to fix, whereas the same bug found post-release costs $16,000, according to research by Capers Jones.
That means that, by shifting left, you can catch bugs before they become critical and much more expensive to fix. With budgets strapped worldwide, any cost-saving activity is going to be music to the ears of tech teams.
Furthermore, incorporating testing into the design phases means that your team can predict bugs before they are even created—ironing out issues before they come to fruition.
When it comes to shift-right, it's true that testing in production is not for everyone.
Risking shipping a product that could contain critical bugs isn't a comfortable choice for smaller businesses, where users haven't necessarily yet bought into the brand. In this case, bugs could deter customers and reduce retention rates.
What's more, as shown by Jones' research, fixing some bugs post-production can be expensive. But shift-right isn't about only testing in production. It's about recognizing that this is a viable option and about continuing to improve product quality long after it has been launched. It's saying that your product isn’t just handed over to ops and left alone.
In short, shifting right is emphasizing the need for continuous improvement.
What you should do next
Don’t get put off by the buzzwords.
Shift-left isn’t just a trend that will be abandoned in a few years' time. Testing early saves costs and improves quality, however it is packaged. Shift-right, similarly, is a concept that focuses on the need for an effective post-production process.
What binds the two approaches is the fact they both improve product quality. And in a saturated market, quality is what’s going to make your product stand out.
So, what can you do next? Step back from your current SDLC process and ask yourself:
- Do I include testing early enough?
- Do I continuously improve after production?
- Does my team have an issue with either, or both?
Draw a diagram of your SDLC. Find the earliest point where testing can be included, and where you can include it post-launch. Ensure that testing isn't just a static block, or step 4 out of 5, similar to the waterfall model. If it is, your QA might be becoming a bottleneck, rather than a vital part of delivering a product that customers love.
This may take some redistribution of resources, tools, and time, but the result will be a streamlined, more effective process.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
