When a company wants to buy LoadRunner, there are a few key pieces of information that you need to find out, before you can actually sell them the product. This can be frustrating for some customers who don’t appreciate that they can’t just walk into a shop and say “I would like to buy one LoadRunner please”.

This Tech Tip contains some of the questions you need to ask during the LoadRunner pre-sales phase…

If you have read my guide to understanding LoadRunner licensing, you would understand that the license cost is based on:

  • Duration
  • Virtual user type/Protocol
  • Number of (concurrent) Virtual Users

Obviously, it is critical that you ask the right questions to get this information, but there are other things you need to know too.

  1. What are they actually trying to achieve?
    Sometimes people get a bit confused and do the equivalent of trying to hammer nails with a screwdriver. This is a good time to make sure that they are actually trying to load test a multi-user system, not just find out the runtime of batch jobs, or the performance of an application that has a single user at a time. Also, do they just want to buy the tool, or do they need someone to drive it for them too (i.e. “professional services”). If this is the case, there are even more scoping questions to ask…but I will save that for a different Tech Tip.
  2. What is their budget?
    You can save everyone some time and effort if you find out early that a potential customer doesn’t have sufficient budget for performance testing. Some people are reluctant to specify an actual number, believing that you are just going to use their upper boundary value for your price quote. If you can’t get an inidication of performance testing budget, then you should still be able to get a rough idea of the overall project budget. i.e. is it a $1 million dollar project, a $10 million dollar project, or a $100 million dollar project. If the overall project budget is less than $100,000, then they don’t really have the budget to include performance testing.
  3. Are they looking at other tools?
    This is always nice to know. Many software companies will not compete in a head-to-head situtation (especially on smaller deals), because after they have helped with all the product comparisons and proof-of-concepts, the cost of making the sale is larger than the revenue that can be made from selling the software.
  4. What are the key dates for the project?
    After taking the dependencies into account (like the system actually being developed and having gone through some form of functional testing), how long do they have for performance testing? If they only have a 1-month window for testing before Go-Live, then they might just want to purchase a 1-month term license. Maybe they will want to perform a regression test (including performance) for each new release, in which case it may make more sense to purchase a perpetual license.
  5. What does the system do?
    Knowing what the purpose of the system is, and who will be using it (internal users, or customer facing) is good to give your conversation some context. A project developing a system for use in banking may be more risk adverse than a company developing a system for the gaming industry.
  6. What is their technology stack?
    This is a conversation best had in front of a whiteboard. Is it an SAP system running on AIX with an Oracle database? Or is it a website written in VB.NET running on IIS with an MS SQL database? This is a conversation you need to have for a few reasons.

    • you want to double check that all the system components have a corresponding LoadRunner monitor
    • you want to get some hints as to what protocol the client uses to communicate with the server
    • you want to identify any other tools that might be useful to them (a sales guy would say “cross-sell opportunities”). Generally this will be HP Diagnostics (if they use Java or .NET), and BPMs if they have not thought about application monitoring in Production. Generally they are talking to you too late in the project to help them with Test Management (Quality Center) or functional test automation (QuickTest Pro), but security is usually an afterthough so they may benefit from WebInspect

    When the infrastructure is drawn on the whiteboard (including how many servers in each tier), it is a good time to draw in the LoadRunner controller and load generators, and talk about how components are monitored and how load is generated

  7. What is the client? How does the client communicate with the server?
    This conversation aims to find out what virtual user type the customer will need, and get some hints on how difficult it will be to create vuser scripts. I have come in to work at more than one client site to find that another company has sold them the wrong license type, and it’s a big pain to sort out. The LoadRunner Protocol Advisor (new in LoadRunner 9.50) makes this much easier for inexperienced people to figure out, but it is still nice to ask to actually look at the application. If it is a browser-based application (rather than SAPGUI, etc), then you should ask some follow-up questions about whether the application uses Ajax, or ActiveX, or AMF, or streaming video etc to see if there will be any difficulties. If it looks like you will have to spend time on a Proof of Concept (read my Tech Tip on how not to do a PoC), make sure that everything else is okay, and the the customer is ready to write you a cheque as soon as the PoC is successful.
  8. How many users will there be on the system at its busiest time?
    This is always a hard question for clients to answer. They generally start with the number of user accounts on the system, rather than the number of people who will actually be using it at the same time. Generally, they will have to go and do a little research for this one by looking at logs etc. Most of the time, clients will initially massively over-estimate (to give themselves a large safety margin). Doing this will make the license much more expensive, as the biggest variable is number of vusers.

Please leave a comment if you have any questions or feedback on this Tech Tip.