From Performance Tester to Performance Engineer

[article]
Summary:
Many performance testers think that after a few years of experience, they automatically become performance engineers. However, it isn't that straightforward; the route to becoming performance engineer is a long and continuous journey. This article details the many things performance engineers need to do beyond performance testing, and it gives an outline for steps to take to advance your career.

I have been working as a performance tester since 2006, and like many performance testers, I used to think that after a few years of experience, I would become a performance engineer. However, I think we need to understand that it is not that straightforward. Instead, the route to becoming performance engineer is a long and continuous journey.

Performance testers need to have not only have strong performance testing knowledge and performance environment setup capabilities, but also a decent grasp of performance analysis and performance monitoring concepts across different types of applications. Performance testers should share performance test results and key findings about the test execution, as well as identify potential performance issues and, if possible, provide some set of performance improvement recommendations.

Performance engineers, on the other hand, identify the root cause of the performance problems, find a possible solution for issues, and do tuning or optimization activities to resolve those issues or ensure the performance parameters or expectations are met.

Performance engineering is an end-to-end activity, and performance testing is a subset of that activity. It’s not like once we have ten or fifteen years of performance testing experiences then we will be automatically transitioned into performance engineers—and honestly, this is with all due respect to performance testing.

In my experience, normally performance testers get onboarded at the end phases of the software development lifecycle (SDLC). However, now a shift left is happening, and more organizations are involved in agile and DevOps methodologies where performance testing is getting allocated at the early stages of the SDLC. This is a positive sign and actually will assist in accelerating the journey of performance testers to becoming performance engineers. Here’s how.

Performance engineering is an ongoing activity throughout all SDLC phases. It aims to design the application by keeping the performance metrics in mind, and to discover potential issues as early as possible in the development cycle. We continue performance engineering activities until the application gets published and meets the overall performance service level agreement (SLA) parameters. If those parameters are not met,  then we do performance optimization at all levels—software, OS, hardware, and network—until the end-user is happy. Performance engineers need to visualize the application’s ideal performance so that application team members can set the right goals and make them into specific, measurable performance metrics.

We must understand that performance engineering is not only performance tuning and optimization, just like it is not only performance testing; rather, these are all activities of performance engineering.

Still, the first step on the long and continuous journey to becoming a performance engineer would be learning performance testing basics. I learned the basics mainly from the internet and my organization’s internal online learning facilities. While involved in actual projects, I started learning automated performance testing tools. The fundamental concepts of all these tools are same, but the tool documentations were very helpful to understand where they differ.

Then, I started learning about performance test execution, result analysis, and reporting with key findings. I think understanding the client-side statistics, like response time, hits per second, throughput, errors, the virtual user graph, and the webpage component breakdown graph, are extremely important. I also learned to look for server-side statistics using different performance counters, such as connecting to the system boxes for Windows-based applications, using system commands for Unix-based applications, or using transaction code for application-specific situations, like for SAP-based applications.

Then I started learning to set up performance environments like controllers, load generators, and data processors. Next, I started gathering knowledge about different monitoring tools, from traditional tools to application performance monitoring tools to digital experience monitoring, for both real users and synthetic monitoring.

On the other side, I am still analyzing performance test results using my own thought process after analyzing the application and server parameters, client and server configurations, test execution details, performance test environment details, testing environmental configurations, performance test data details, and discussions with stakeholders and other teams, all to improve the overall performance and established benchmark for future references. There are so many things to learn here, based on different types of applications, their underlying communication architecture, and business domains.

Then comes the performance optimization and tuning phase. I have categorized the topics to study into three segments: server levels (web, app, and database), OS levels, and device and network component levels. As a performance tester, we have huge chances to suggest different recommendations (with key findings) for overall performance improvement, as we already have years of knowledge in these areas. By doing that we can build confidence and start really looking into the opportunity to work as a performance engineer.

This is why I think of it as a long and continuous journey to transform ourselves from performance testers to performance engineers. I’ve found it easier to go down the path by following step-by-step activities, like becoming an expert performance tester first, then adding performance environment setup capabilities, and finally becoming a performance analysis expert with good overall performance monitoring concepts. These are fundamentals of performance testing that we just need to build on.

For that, we have to get hands-on experience with profiling or diagnostic tools, spend time learning, and seek out possible opportunities. Here is a list of performance testing concepts we should all focus on developing: 

  • Performance requirements gathering
  • SLA finalization
  • Preparing transaction traversal documents for business-critical scenarios
  • Writing detailed performance testing strategies
  • Designing proofs of concept
  • Workload modeling
  • Automated performance script creation for multiple users and multiple iterations
  • Different ways of performance data preparation for handling multiple users
  • Types of performance test executions to meet real user simulation
  • Performance test reporting (both preliminary and executive), including results analysis
  • Performance monitoring with both client-side and server-side statistics
  • Performance improvement recommendations
  • Performance environment setup based on available resources, tools, and the underlying communication mechanism

Performance engineering is end-to-end work. The whole objective is to ensure proactively that any product meets the performance requirements and to identify and resolve performance issues before real users face them. Transitioning from a performance tester to a performance engineer is a long and continuous journey, but by breaking down that journey into step-by-step activities with defined learning goals, you can formulate a plan for your career development.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.