1 Incorrect Load Levels
Fix: Improve and focus communications by conducting a one-on-one interview to determine expected “real world” load levels. If the application is already in production, obtain live usage data.2 Performance Tester Identifying Key Business Processes
Fix: Conduct a one-on-one interview to identify key business processes: mission critical, heavy throughput, dynamic content, and any other business process that causes concern.
3 Too Many Business Processes
Fix: Concentrate on a few, perhaps 6-8, key business processes for performance testing – this is not a functional test.
4 Altering Load Test Objectives
Fix: Develop a complete custom plan with goal load levels, business process steps, transaction names, and acceptable response times. Analyze any missed objectives – stay consistent with the original goals unless there is a compelling reason for change.
5 Late Focus on Performance Testing
Fix: Engage the performance testing team as early as possible in the development life cycle to allow time between executions for a good analysis of the results from the performance tester. Detecting and correcting performance issues early reduces the repair cost.
6 Poor Transaction Naming Convention
Fix: For easier analysis, maintainability, future growth, and possible server consolidation, provide a clear naming convention.
7 Performance Tester Stands Alone
Fix: Let the experts do what they do best. Involve all members of the team: the DBA, Web Server Expert, Application Expert, Developer, etc. Executing a performance test is best done as a team.
8 Not Validating the Execution Transaction Levels
Fix: Validating transaction levels against the test plan after executing a full load test ensures the test presented the desired load to the application.
9 Server Experts Become Bouncy
Fix: If possible, don’t bounce the server between test executions. Bouncing the server prior to every test causes the need to rebuild the memory and cache. Memory leaks and other reliability and availability issues will be more easily identified if the server is left untouched.
10 Over-technical on Results Reporting
Fix: Performance testing creates mountains of data that are usually very interesting to technical experts. Ultimately, however, the owners of the application are looking for key performance indicators to make a sound business decision for their application go-live. Create a one-minute overview for managers that concisely conveys the critical data related to application performance.
Good post! We will share this Top Ten with our loadRunner communities on Twitter, Facebook, and LinkedIn.
LoadRunner By The Hour
I know that ranking engines love top 10 lists, but seriously? These are certainly not the top 10 (and even if they were, they're not in order), they aren't even unique.
Of course, my real complaint is that there are no references or attribution. I simply can't take seriously a top 10 list that doesn't so much as answer the question "According to whom?"
Sorry, but even though these are items worthy of consideration, they do not a top 10 list make.
—
Scott Barber
President & Chief Technologist, PerfTestPlus, Inc.
http://www.perftestplus.com
sbarber@perftestplus.com
Executive Director, Association for Software Testing
http://www.associationforsoftwaretesting.org
executive.director@associationforsoftwaretesting.org
"If you can see it in your mind…
you will find it in your life."
Sir, I am gratified you commented on my post 🙂
"I know that ranking engines love top 10 lists".
No No, This title is not for engines, even I don't know that engines love this tag – Top 10.
From this list, few items are from my experience and many are collected from google.
As per my experience, these are still Top 10, because I am not much experienced in Performance testing. I am just another software tester with 3 years of experience 🙂
I always add those topics which helps me.
But these are not top 10 for others. So i am changing this post title.
BTW, I love your testing suggestions on searchsoftwarequality.techtarget.com
Thanks again for commenting here.