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.
Please scroll down further to see the table :)
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.
Top comments (0)