Shift Left Testing and Shift Right Testing Approaches
This tutorial discusses two important testing approaches i.e. Shift Left testing and Shift Right testing. Let’s first look at the ‘Shift Left’ testing approach.
Traditionally, for example, in the waterfall model, the phases of the life cycle were linear. In order to the next phase to start, the previous phase should have been completed. For example, until the development phase completes successfully, the next phase, the testing phase cannot start.
Disadvantages of Traditional Testing
- If any of the phases delays and the team is not able to complete them at the desired time. It directly affects the timelines of the next phases.
- If the requirements gathering or design or development phase is completed late, its impact would be on the testing phase.
- The testing team will not get enough time to complete the testing process as the deadline will approach quicker than expected. Again, if the testing is not completed properly, it affects the quality of the system.
Due to this and many other drawbacks related to the late beginning of the testing phase, a shift left testing approach was introduced.
Shift Left Testing
The term ‘Shift Left’ was invented by Larry Smith in 2001. The name shift left suggests shifting left in the project cycle i.e. starting the testing process early in the project life cycle.
The idea is to find the bugs as early as possible that will eventually cost the organization much less compared to finding any critical bug in the UAT or on the production that would cost more.
What is Shift Left Testing?
In the shift-left testing approach, the testing team is involved early in the project lifecycle. From the initial phases i.e. requirements gathering and analysis part, testers are included in the discussions.
Due to this, the testing team can understand the basics of the requirements. Moreover, they give their inputs on any potential risks, start working on the test strategy, etc.
They can be asked to review the requirements specifications to find any missing and ambiguous requirements. By the time the development phase starts, testers are clear with the requirements. They can start working on the test scenarios and test cases.
This will eventually help the testing team to get ready for the actual testing process; when the development team is ready with the code, the testing team will be ready, too.
The testing team starts testing the system in parallel to the development phase. The team helps in code review, helps in creating unit tests, performs integration testing.
If the bugs are found early, the development team has enough time to solve them. As compared to the traditional model scenario where the critical bugs are found late in the testing cycle.
And due to tight deadlines, the project manager is eventually forced to postpone the release.
Types of Shift Left Approach
Before we begin this section, kindly keep in mind the V model as it will help in visualizing the discussion.
There are mainly four types of the shift left approach i.e. there are four ways using which shift left testing can be incorporated in the project lifecycle:
Traditional Shift Left Testing
In this approach, instead of system and acceptance level testing, the testing focus is on unit testing and integration testing. In other words, we can say that the focus moves lower down on the right side of the V – model and thus shifting left.
Incremental Shift Left Testing
In this approach, large development is divided into multiple smaller increments with small durations. So, a single V – model is divided into multiple individual V – models for each increment.
So, in this approach, the shift-left happens by moving to the left. This is done by breaking the single development into increments. The first increment is developed and tested and then move to the next increment and so on. This approach is popular among projects with complex hardware dependencies.
Agile/DevOps Shift Left Testing
This approach is similar to the second approach i.e. incremental shift-left testing. Agile and DevOps projects are divided into multiple increments called sprints. These are smaller and more in number as compared to the incremental shift left testing approach.
The difference between agile and DevOps in this context is that agile includes development testing and not operational testing. Operational testing happens when the system is live.
Model-based Shift Left Testing
In this approach, the testing begins at the very initial phases i.e. requirements and design phases rather than waiting for the development phase to start. The idea is to find defects in these initial phases. At the same time solve them as early as possible before the development phase starts.
Now, let’s look at the shift right testing approach.
Shift Right Testing
The shift-left approach helps in identifying bugs early in the project lifecycle. But what about the user experience? And system performance once it has been deployed?
The answer is shift right testing.
What is Shift Right Testing?
The shift right testing approach is doing the testing later i.e. once the system is live or the code is deployed on the production. By shifting right, we are moving the testing process on the right i.e. moving it to the post-production stage.
The main goal of this approach is to continuously check the performance and usability of the system once it is available for the real user’s consumption. Also, with the help of the end users, feedback of the system is received.
This approach is mainly used in DevOps. DevOps focuses on delivering rapid and high-quality products. DevOps, as the name suggests, brings the development and operations teams together.
The development team takes help from the operations team. They take continuous feedback from them regarding the features and functionalities.
Moreover, the feedback received from the end-user, production data, end-user usage pattern on the production, etc. can be combined with the AI and ML to develop new and improved features for the system.
Methods of Shift Right Testing Approach
This section discusses some of the methods or concepts used in the shift right testing approach.
- Beta Testing – In this method, the product is released in the market for a specific set of users. After that their feedback is gathered.
- A/B Testing – In this method, two similar versions of the product with minor differences, are released in the market. This is done for two similar sets of users. This method is used in analyzing end-user behavior.
Let’s take an example of an e-commerce website. There is a banner with some promotional code and the ‘Buy Now’ button. The organization can come up with two different banners and conduct A/B testing. After that, they will see which banner had the highest clicks.
- Chaos Testing – In this method, failures or errors are introduced in the system deliberately to see how the system fights back and recovers from it. System performance is monitored along with all the functionalities. This helps in increasing system efficiency and quality by solving bugs found during such sudden attacks.
- Dark Launching and Feature Flags – In this method, new features are released to a specific set of users, without letting them know. The users are in the dark about the new features and discover them while using the system.
The main goal of this method is to observe user behavior, get their feedback, find any bugs. And finally see if the new feature can be released for a larger audience or not.
Another method is a feature flag that can be used with dark launching. Once you have released the feature and if it does not seem to be working. Using the feature flag technique allows the team to turn off the flag for the feature and roll back it, if necessary.
Both the shift left and shift right approaches are useful for a successful project.
The shift-left approach is used during the development life cycle. It involves the development and testing teams. This approach helps in finding out bugs early in the development life cycle.
With this approach, the focus is on testing the system once it is deployed on the production. It typically involves the development team, operations team, and end-users of the system.