In my last post, I have shared my views about James Pulley’s latest book Interviewing & Hiring Software Performance Test Professionals. 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.
Traits
| Good Performance Test Engineers | Bad Performance Test Engineers |
| always cares for performance | has a who cares mindset |
| always learn new technology, tools, and products | won’t learn anything new |
| involved in all the phases | involves only in testing phase |
| understand the architecture, network, protocols, and business transactions | understands only business transactions |
| develop a strategy to find performance issues | do ad hoc runs |
| starts with single user testing. | directly goes to load testing |
| validates their scripts using unit/smoke testing | don’t pay attention to unit/smoke testing |
| starts the test and observe the whole run. | starts the test and run for a coffee or tea. |
| validates the test data before starting the test. | keep on reusing the test data |
| validates the response properly | validates only the status code |
| loves automating other tasks | don’t do automation |
| carefully develop workload model | follows a generic workload model |
| knows how the production environment works. | no insights into the production environment |
| validates the runtime settings, logging level, duration, and other configuration | don’t pay attention to the configuration and reuses them |
| analyze the test results and provide value to the report | copies the test result and share it with the stakeholders as it is |
| deep dive into response time, transactions pass/fail, throughput, errors per second, CPU, Memory, Network, Disk, Garbage collection, and more. | limited to response time analysis |
| knows statistical methods | don’t apply statistial analysis |
| validates the database or other means after the test is done | don’t perform any validation |
| validates the performance tool infrastructure | don’t validate the test infrastructure |
| works closely with architects, developers and product owners | no or limited interactions with the team |
| implements CI/CD and integrates with the dev pipeline | no CI/CD mindset |
| share knowledge and document the findings and best practices. | don’t share their knowledge and no/limited documentation |
| takes full responsibility for missed defects | don’t take responsibility and blames others |
| keep improving their tests and adapt to new features and releases | follows a process for prolonged duration. |
| good at communication and proactive in raising issues. | bad/unclear communication and reactive in raising issues |
| brings value to the team, product and organization | brings no value |
If I miss anything critical, please share it in the comment.