With the recent industry trend for ‘Continuous Integration/Continuous Delivery’, there is a move ‘Shift Left’ came into the picture. One of the major benefits seen with this move is to reduce the issue’s/defect’s cost by finding it at an early stage.
In this article, the performance experts at SDET Tech will explain the Shift Left Approach in performance testing. Like functional testing, Shifting left is nothing but starting performance testing at early stages on lower environments.
Importance Of Shifting Left The Performance Testing
Unlike functional testing, it’s not that straight with performance testing since it needs the functionally stable builds to test. Before moving forward, let’s quickly revise the basic performance test process:
Performance test starts with scripting the test scenarios which is actually gathering or listing the APIS to be tested and make them dynamic with place holders and correlations
Now when the new build comes in, a Performance engineer has to repeat step #1 above to capture the APIs again and verify if there is any change(s)
Fix and update performance test code for new build
Set up the test and execute
All above points are expensive in terms of time and effort though point #1 to #3 costs most of it as there can be various builds against the bug fixes or enhancements.
So it would not be an understatement saying – saving this time and effort will reduce most of the performance test process cost.
Let’s look at some basic mathematical expressions to understand its effect on the project life cycle:
Consider following if:
Overall Delivery Time = T daysDevelopment Time = Dn days andPerformance testing time = Pn daysPerformance code verification and update time = Pu daysPerformance test data and test execution time = Pe days
Over all performance testing time will be:
This is to note that Pe is the time for test execution so it is so well understood that:
The below picture depicts the traditional approach and the associated cost in terms of days
Now the time to see how it will look with Shift Left:
In figure 2.0, it is clear that time cost has been reduced by Pu days and it is a significant cost to save as shown in expression 1e.
Add-Ons to the approach:
Having a performance test ready at an early stage, can help testing Individual features or until tests at API level. So API level tests can be covered using the performance test code even earlier in development phase
Also it makes performance testing possible at feature level on lower environments with some production parity (reduced load as per the available machine size/config)
And of course, It makes release cycle faster with continuous delivery
Performance engineering experts at SDET Technologies have a good experience setting this up efficiently in project processes and support faster and cost effective deliveries.