The meaning of performance engineer is subjective as of now. Let’s try to break it. Performance is a quality attribute that cannot be achieved in an SDLC phase. To assure performance, you need a lot of players in SDLC phases, but you can’t call everyone performance engineers. We need architectural/design expert, UX designer, development lead, performance tester, capacity planner, etc. to assure my digital product performance and therefore user experience.
Performance engineering is a discipline that involves systematic practices, techniques, and activities during each phase of the SDLC to meet the performance requirements. It strives to build performance standards by focusing on the architecture, design, and implementation choices.
Ideally speaking, performance being one of the CTQ (Critical to Quality) attributes, it needs to be proactively thought of throughout the software development phases right from the requirements phase until you get to ongoing production maintenance.
In this proactive mode, a Performance Development Engineer (who is a solutions architect with technology expertise aware of the right architectural and design pattern choices for system performance and scalability) should be involved right from the initial SDLC phase to ensure the system is built with performance standards.
In a more reactive mode, system performance is not thought about until the end of implementation/functional testing phase, leading to reverse engineering of the digital product, sometimes leading to architectural/design level changes. In a proactive or reactive mode, when a Performance Test Engineer tries to test and assess the developed system for its performance, and when SLAs are not met, he performs a deep dive analysis on the specific layers that don't meet the SLAs.
In this case, depending on the type and complexity of the bottleneck being analyzed, deep dive analysis and tuning can be done by yourself, or specialized SMEs like DB Architect, Websphere specialist, Network Engineer, etc can be involved to analyze the performance issue in detail to provide tuning recommendations. (Note: I hope we all accept the fact that a Performance Tester should have the capability to test and assess performance problems in a system at all layers and report RCA findings, whereas a Performance Engineer is an experienced person who can be a technology expert with good bottleneck analysis/tuning skills to provide recommendations for fixing the issue. But ideally a sound Performance Tester, upon gaining experience, develops the skills of a Performance Engineer).
Gaining Clarity on the Contradiction
Here comes the disagreement. If you notice above, in both proactive and reactive modes, a Performance Engineer is involved. But note I have called the former a Performance Development Engineer and the latter a Performance Test Engineer. The skills of a Performance Development Engineer can be very different from those of a Performance Test Engineer.
But we need to remember that we can have both Performance Development Engineers and Performance Test Engineers available from the early SDLC phases, as both are not duplicating their skills. They are actually complementing each other. Testing done by the development team (unit testing) and testing done by the testing team (system testing) have their own objectives and advantages. They complement each other and try to find as many defects as early as they can to reduce the cost of fixing the defect.
I look at a Performance Test Engineer to be a Performance Assurance Expert, where (s)he need not be a technology expert (building systems with performance in mind is the job of a Performance Development Engineer), rather (s)he needs to look at the digital product from all perspectives to validate whether it will create a great user experience by providing expected performance.
Apart from the knowledge of various testing, monitoring, and APM tools, (s)he needs to be aware of technology-agnostic performance principles &and know how to detect performance issues by strategizing the right type of performance tests with the right workload model. With thorough performance bottleneck analysis skills across all layers, there needs to be a mature thought process upon considering when my hardware will saturate/reach its thresholds, affecting the scalability (though that person might not be a capacity-planning expert).
Hidden Track of Performance Engineering
Though performance engineering is itself very broad, there is something that is hidden or forgotten. It has not gained much popularity comparatively, and we don’t find people with these skills very often.
Being the performance assurance expert, a Performance Engineer also needs to be capable of employing scientific/mathematical principles to engineer various test activities (like verifying whether a test or workload is valid mathematically, forecasting peak traffic hour workloads, determining how to map test results from low-end environments to PROD hardware, etc.), to perform prediction or performance extrapolation, to bring in mathematical strategies to model and validate the performance even before the system is completely built, etc.
Generally speaking, with respect to Test Competency, every Performance Tester aspires to become a Performance Engineer who is well-versed in bottleneck analysis skills, profiling, tuning, etc. But I have met very few Performance Testers who aspire to gain knowledge on Queuing Theory principles to get their feet into the door of this hidden world of performance prediction, modeling, and application capacity planning. This track is the basis for the onset of high-end capacity planning tools and the recent boom in Performance analytics and predictive/prescriptive modeling on performance data. Many businesses are experiencing huge demand for this skillset.
Performance Test Engineers need to have plans to expand their knowledge on this space in order to have a successful, educational career.
If you disagree, don’t forget to share your point of view, for the benefit of Performance Testers/Engineers. Together, let's strive to create more awareness and remove any subjective usage of terms and hold the torch to light up the hidden tracks.
Happy performance testing and engineering!!