Performance Testing, LoadRunner Tips&Tricks

This site is moving to a bigger space @ LoadRunner TnT

General: Planning for Load Testing - Soliciting Requirements

Prior to this stage, I always give a “sales talk” of what we do for a living and also to get them excited (if they are not). Gathering and soliciting accurate requirements will save you lots of unnecessary work.

Be sure to get hold of the requirements to monitor such as acceptable Transaction Response Time or server utilization. Clients need to be clear of what they want before you can proceed to achieve (unless is you who proposes the benchmark). For example, if CIO wants the response time for a search to be fewer 10 seconds will be a good metric to achieve. This is also the exit criteria as per se for the load test project.

They may also like to know the utilization of the servers under load and not really concerned with the response time. Usually, these are applications that are already problematic and it’s what they are hiring you to dig the cause of the bottleneck.

Always get an overview of the architecture which includes all components that inhabitant it. You can leave out the number of switches or routers if they do not provide much usage except routing and separating networks. It is important to get information like number of servers and what is housed in it, load balancers, firewall and databases. This will aid you in discussion and knowing what machines to be monitored.

Assist the clients in understanding which business process may raise performance issues or they see it’s criticality in the business competitive edge. With this, it can translate into the scripts that will be used in the load test.


Related Topics

General: Planning for Load Testing
General - Content Page



Labels: , ,


Bookmark this article now! AddThis Social Bookmark Button



technorati del.icio.us reddit digg

1 Responses to “General: Planning for Load Testing - Soliciting Requirements”

  1. # Blogger Converged

    One major problem typically occurs while planning for load testing. The technical team is called upon to translate business requirements (numbers of users, types of services, customer care volumes, etc...) into downstream transaction rates. The translation is often flawed and the results is a lack of consensus among teams, misunderstanding of SLA requirements and at worst an under or over investment that either costs the company too much or causes a service impacting event. We have found that the most critical aspect of requirements gathering when preparing for load testing is in mapping the market demand loads to the downstream process transactions. This eliminates the confusion across departments and ensures that the planned tests use highly probable loads rather than a plug number such as 2x or 5x some transaction rate in which confidence is not high. The impact is worse when multiple coincident loads need to be tested. Defining highly probable coincident loads is critical to ensure the tests capture the right scenarios.  

Post a Comment


Powered by Google

Enter your email address:

Delivered by FeedBurner


Add to Technorati Favorites


XML

Powered by Blogger

make money online blogger templates

Powered by FeedBurner

Blog Directory

Top Blogs

Software Blogs -  Blog Catalog Blog Directory





© 2007 Performance Testing, LoadRunner Tips&Tricks | Blogger Templates by GeckoandFly.
No part of the content or the blog may be reproduced without prior written permission.
Learn how to make money online | First Aid and Health Information at Medical Health