• What is the total user base?  What is the concurrent user base? – Now after working the maths out, do you required a load test.  Example, is a 5 concurrent user base an effective load test?  Is it worth the effort to generate a script that emulates 5 concurrent users?  Your customer may want you to run a load test for 5 users even though it is not effective to run that kind of load test.  However, if it is in the contract, you may have obliged it.  If they are willing to pay for that service, then it’s a plus point!
• Do the available load testing tools support your system in a load test? – A very strange question to ask.  Most tools are unable to support asynchronous application and map applications.  Either you may have to purchase more licenses to run the load test like in LoadRunner, find alternative sources or write scripts to emulate the load.  There are multiple ways to run a load test however may require additional effort (which translates to additional time).  Most tools are useful in coordinating and reporting which your scripts may not be able to achieve.
• What is the environment that you will be conducting the load test? – At times, your load test may be conducted in a scale-down production environment which you may know.  The load test results may not be a good representation of the true performance of the load test.  However, most of the times, running in production is a no-no and it is good to align everyone’s (stakeholders, customers, etc.) expectation of the load test.
• Where do you want the load to be generated to? – For a web application, there are multiple layers that you can access the system.  You can access the normal URL that can be the virtual IP address from a central web server.  You can enter at the load balancer or the web server layer.  Lastly, you can enter at the application server layer.  Where you want the load to enter can help you determine the layer that can be causing the performance problem.  By stepping up from the application layer, you can determine stage-by-stage the layer as the source of bottleneck.
• What do you want to monitor? – There are so many things that you can monitor in an infrastructure.  Which one do you want to focus on your analysis effort on first?  Do you want to monitor all sub-systems or target your effort to the most possible source such as the database?  Setting up monitors takes effort.  What’s more tedious is the effort required to analyze the monitoring results that you have collected!  Therefore, do take note and factor the duration and effort!
• Do you know the backbone network infrastructure? – This information is usually not available to a load tester.  But if you know this, you can least prepare your team that the load test will bound to meet (or not bound to meet) performance issues during the load test. They can be ineffective load balancing, small bandwidth available, invisible proxy that limits bandwidth, etc.  If you do not know this information, it is best to work on those you know such as the method previously mentioned by running the load test stage-by-stage.
• Is your load test conducted in a wireless environment? -  A wireless environment may be limited by the number of access point and the bandwidth available per wireless network. You need to know if the wireless will become a potential bottleneck in the amount of clients that can be generated into the system before your load test.
• Do you have a base set of data to use in a load test? – Most often after a load test, the data in a database will likely be messed out.  Therefore, it is advisable to create a backup of a working set of data in the database for you to reload after each load test.

1. Do you have sufficient hardware? – How may load generators are required for the entire load test?  Refer to this document from HP Support, “Is resource (cpu and memory) footprint information available to help in estimating the load generators required for load testing with LoadRunner?” for estimating the load generators required by multiplying the observations with the total number of virtual users generated in the test.   In addition to the processor utilization recommended in the document, do watch the memory and network consumption of the load generators.   The network interface card (NIC) can become a bottleneck for load generation.  A 1GB NIC will definitely generate and receive more load than a 100MB NIC.  Therefore, do a check on the machines assuming the load generator roles and make appropriate measures to prevent the NIC in becoming the bottleneck.   With the above, you will get a rough gauge of the required resource for your test.
2. Do you need spare hardware? – Do cater some spare machines if additional load generators are required, such as an additional of 5 load generators.  This is to stand by in the event of increasd virtual users and machine malfunction.
3. Remember that it’s a team effort! – Can you secure human resources for the load test?  You will need the web, application and database server teams to be around to observe the system behavior during the test or to assist in any reboot or refresh activities for the system.  Network and firewall/security team may be required to ensure that connectivity is allowed for the load test.    Therefore, in the planning, you have to get the relevant parties to commit the human resources!
4. Installation of LoadRunner – This require administrative or power users privileges in order for installation to be successful.  That raise another set of questions: Will you be able to install LoadRunner in the premises?  Who can you look for to install the LoadRunner program?  Do you need clearance for installation?  Is the system being hardened to prevent installation?
5. Offshore Installation – Is offshore installation required for the load test setup?  Can you perform the installation via remote connection or do you require someone from the site to assist in the installation?
6. Running of JVM/.NET Probes for Diagnostics – This will require installation and instrumentation on the application server, meaning it will be intrusive to the system as a whole.  Do you require additional permissions for such installation?
7. Post-installation – Do remember to test if the installation is complete and the programs are working before moving on to the next phase.  Remember to do a connectivity check between the load generators to the controller to ensure they communicate prior the load test.
8. Working in different environments – Are you required to work in different stages of a load test project?  Example, you are required to run the test in (A) the  data center followed by (B) the local client segment and lastly (C) the remote client segment?  In this context, how do you ensure the scripts worked from A to C?  It will be easy if it is a change of hostnames and URL addresses that is being used in these environments as it can be achieved through parameterization.  But what if there are additional authentication mechanism introduced in environment B and C?  Authentication mechanisms such as additional cookie in the clients are added into the URL or 2-factor authentication can render the scripts developed in environment A useless!  How do you go about it?  Should you cater more time to re-script for the worst scenario or is it better to disable the authentication mechansim during the load test?

These are some basic considerations we usually asked our ourselves and clients.  Hope it will be useful in your planning.  What are other considerations make for a load test for you?