Early Performance Testing/Engineering

Performance testing in the early phases of SDLC delivers business benefits to the end customers in the most efficient and cost-effective way. This will also help in considering performance testing as part of the continuous integration process and not a standalone exercise late in the game.

Performance Testing is the most crucial phase of any project before it is set for production to go live, and most of the performance testers will have very tight project schedules and less duration for performance testing the applications. The phase that determines the user experience, which is of high significance to the end user, will have limited time and that is the time when project go-live dates are postponed due to performance bottlenecks.

Of course, the application is functionally stable by the time performance testing is planned/scheduled. The application bottlenecks/issues can be detected {can we say it needs to start from planning for performance right from architecture and design definitions!! (just to introduce our early involvement of performance architect into the product life cycle)} only during performance test executions and detecting them at a later phase is always expensive.

With many emerging technologies and multiple options to present data (Dashboard View etc.,), the end user always expects web pages to respond very quickly within the specified SLA without any delays or server errors. Most of the performance bottlenecks could be due to lousy database calls, too much synchronization, memory leaks, poorly designed web front end, load balancer issues, and incorrect estimates for the workload distribution (load profile). Identifying all these issues at a later part will have a cost impact and the Development team cannot afford to build performance considerations into the application lifecycle. It will be tough for developers and database administrators to look into the code/queries and make necessary changes at the end when the code is completely developed and signed off.


Keeping all the above factors into consideration, performance testing should ideally start in parallel with code development. This ensures that performance testing will always remain an additional, integral requirement in software development. Also, with the advent of Agile methodology adoption in place of the traditional waterfall model for software development life cycle, Performance testing activity needs to be part of the agile delivery model to make sure performance testing is done at the component level and all the individual components meet the specified SLA before they are integrated to one application.

The advantages of starting performance testing in early phases along with development will ensure the below objectives:

• Gather all performance-related requirements and address them during system architecture discussions and planning.
• Work closely with end users and stakeholders to define acceptance criteria for each performance story.
• Involve performance testers early in the project, in the planning and infrastructure stages.
• Ensure that the performance testers work on test cases and test data preparation while developers are coding for those user stories.
• Get performance testers to create stubs for any external Web services.
• Deliver each relevant user story to performance testers as soon as the functional testers sign it off.
• Provide continuous feedback to developers, architects, and system analysts.
• Share performance test assets across projects and versions.
• Schedule performance tests for off-hours to increase the utilization of time within the sprint.
• Performance testing at the code level.
• Performance testing or response time testing for newly developed features during the sprint.
• Performance regression testing for the system integrated with newly developed features.

Several examples of early performance testing were implemented successfully in the projects where the entire API calls were tested individually until the specified performance and business SLAs were met. This helped in identifying typical problems at until level such as deadlock detection, memory leaks, query optimization; architecture issues, etc., and ensuring the API response time meets the associated e2e SLA requirements.

Approach
Below is the approach in which API calls are tested while code development is in progress and the performance testing team in collaboration with the Development team successfully tuned the performance of individual modules and after all the code fixes are done, a successful integrated load test is executed. This method was successful as it was cost-effective and all the teams understood the requirements and the outcome was a perfectly tuned application, which has responses within the specified SLA.

API Performance Testing Process:

This approach helped in analyzing performance defects well in advance and developers were able to tune the components before they are integrated. When the integrated application was performance tested there were minimal defects and less performance tuning effort for developers which resulted in cost-effective and efficient project deliverables. With this approach, we were successful in reducing the cost and expediting delivery with a proper review mechanism in place.

About the Author
Name: Jagadeeswara Reddy Katamareddy

Email Id: Jagadeeswara.Katamareddy@prolifics.com

Jagadesh is the head of Performance Testing & Engineering at Prolifics using open source (Jmeter) & commercial tools (HP LR, IBM RPT, Neoload, VSTS & Silk Performer). He has strong expertise in API Level performance engineering/early Performance testing, thereby identifying the bottlenecks early in the SDLC. He is also an aspiring blogger who likes to share the happenings in Performance Testing & Performance Engineering through his blog