Shift Left The Performance Testing

Introduction

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 iTransition 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:

1. 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
2. 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)
3. Fix and update performance test code for new build
4. 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 days
Development Time = Dn days and
Performance testing time = Pn days
Performance code verification and update time = Pu days
Performance test data and test execution time = Pe days

Add-Ons to the approach:

1. 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
2. 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)
3. And of course, It makes release cycle faster with continuous delivery

Performance engineering experts at iTransition have a good experience setting this up efficiently in project processes and support faster and cost effective deliveries.