Good Vs Bad Performance Test Engineer
Tags: webperf, performance, testing
Published: 2021-11-11 17:48:29

<!-- wp:paragraph -->
<p>In my <a href="https://qainsights.com/interviewing-hiring-software-performance-test-professionals-book-review/" target="_blank" rel="noreferrer noopener">last post</a>, I have shared my views about James Pulley's latest book <a href="https://amzn.to/3wlB6zw" target="_blank" rel="noreferrer noopener">Interviewing &amp; Hiring Software Performance Test Professionals</a>. The first chapter deals with the cost of hiring bad talent and its consequences. So I thought, why not come up with what good and bad performance test engineers do in their project. I hope this comparison will help you to transform into a valued performance test engineer and avoid the mistakes of bad performance test engineers. Let us see the difference between good and bad performance test engineers' traits. </p>
<!-- /wp:paragraph -->
Please scroll down further to see the table :)
<!-- wp:heading -->
<h2>Traits</h2>
<!-- /wp:heading -->

<!-- wp:table {"style":{"color":{}},"className":"is-style-stripes"} -->
<figure class="wp-block-table is-style-stripes"><table><tbody><tr><td><em><strong>Good Performance Test Engineers</strong></em></td><td><em><strong>Bad Performance Test Engineers</strong></em></td></tr><tr><td>always cares for performance</td><td>has a <em>who cares</em> mindset</td></tr><tr><td>always learn new technology, tools, and products</td><td>won't learn anything new</td></tr><tr><td>involved in all the phases</td><td>involves only in testing phase</td></tr><tr><td>understand the architecture, network, protocols, and business transactions</td><td>understands only business transactions</td></tr><tr><td>develop a strategy to find performance issues</td><td>do ad hoc runs</td></tr><tr><td>starts with single user testing.</td><td>directly goes to load testing</td></tr><tr><td>validates their scripts using unit/smoke testing</td><td>don't pay attention to unit/smoke testing</td></tr><tr><td>starts the test and observe the whole run.</td><td>starts the test and run for a coffee or tea.</td></tr><tr><td>validates the test data before starting the test.</td><td>keep on reusing the test data</td></tr><tr><td>validates the response properly</td><td>validates only the status code</td></tr><tr><td>loves automating other tasks</td><td>don't do automation</td></tr><tr><td>carefully develop workload model</td><td>follows a generic workload model</td></tr><tr><td>knows how the production environment works.</td><td>no insights into the production environment</td></tr><tr><td>validates the runtime settings, logging level, duration, and other configuration</td><td>don't pay attention to the configuration and reuses them</td></tr><tr><td>analyze the test results and provide value to the report</td><td>copies the test result and share it with the stakeholders as it is</td></tr><tr><td>deep dive into response time, transactions pass/fail, throughput, errors per second, CPU, Memory, Network, Disk, Garbage collection, and more.</td><td>limited to response time analysis </td></tr><tr><td>knows statistical methods</td><td>don't apply statistial analysis</td></tr><tr><td>validates the database or other means after the test is done</td><td>don't perform any validation</td></tr><tr><td>validates the performance tool infrastructure </td><td>don't validate the test infrastructure </td></tr><tr><td>works closely with architects, developers and product owners</td><td>no or limited interactions with the team</td></tr><tr><td>implements CI/CD and integrates with the dev pipeline</td><td>no CI/CD mindset</td></tr><tr><td>share knowledge and document the findings and best practices.</td><td>don't share their knowledge and no/limited documentation </td></tr><tr><td>takes full responsibility for missed defects</td><td>don't take responsibility and blames others</td></tr><tr><td>keep improving their tests and adapt to new features and releases</td><td>follows a process for prolonged duration.</td></tr><tr><td>good at communication and proactive in raising issues.</td><td>bad/unclear communication and reactive in raising issues</td></tr><tr><td>brings value to the team, product and organization</td><td>brings no value</td></tr></tbody></table><figcaption>Good Vs Bad Performance Test Engineer Traits</figcaption></figure>
<!-- /wp:table -->

<!-- wp:image {"align":"center","id":8862,"sizeSlug":"full","linkDestination":"media"} -->
<div class="wp-block-image"><figure class="aligncenter size-full"><a href="https://qainsights.com/wp-content/uploads/2021/11/Thank-you-for-being-good.jpeg"><img src="https://qainsights.com/wp-content/uploads/2021/11/Thank-you-for-being-good.jpeg" alt="Good Vs Bad Performance Test Engineer" class="wp-image-8862"/></a><figcaption>Good Vs Bad Performance Test Engineer</figcaption></figure></div>
<!-- /wp:image -->

<!-- wp:paragraph -->
<p>If I miss anything critical, please share it in the comment. </p>
<!-- /wp:paragraph -->