It doesn’t matter, just do it! Lots of people get into arguments over terminology about different IT concepts. My view has always been that each organization or even each team decides its own terminology. In short term, if they manage to communicate with each other and produce quality software, it doesn’t really matter how they do it. But once they start talking to other individuals, other teams, other organizations, other countries it is useful to have common terminology. So call performance testing performance testing!
That said, all the three words - performance testing, load testing, and stress testing – are actually all used in this domain. ISTQB syllabi (which in turn reference number of standards from e.g. IEEE and ISO) define performance testing as the main term. This is the testing that relates to how fast the software or system is.
Performance testing also means the first step of a performance testing “project”: defining whether an individual function is slow or fast, even with just one user. So if a software developer measures the response time of one component, that is performance testing. Or if a system tester measures response time of one user using some functionality in software that is performance testing. The next step would be load testing. That means that you create load to the system, e.g. have 100 users use the system at the same time. And then you measure the performance of each user. Is it still fast for each user? The final step is stress testing. There you push the system over its design limits. So you keep adding load into the system, e.g. by increasing number of concurrent users up to 2000, until the system starts slowing down or exhibiting other problems. To simplify, performance test with one user, load test with intended number of uses, and stress test with as many users as you can.
All this is usually done with performance testing tools. There are commercial tools and open-source tools. Commercial ones often have more built-in functionality, whereas with open-source ones you have to spend more time to do some activities manually. The tools measure response times, they generate load to the system using virtual users, and they create reports and offer analysis opportunity. Different software domains have dedicated performance testing tools, e.g. there are specialized performance testing tools for telecoms networks.
Why would you engage in performance testing? You want to make sure the system works regardless of the number of users. Each user should have the same experience, a fast, nice user experience. So good performance is really part of UX, user experience. Or should be, in any case. Too often the UX designer thinks about a nice look-and-feel that is only possible for one user in an optimized test environment. Real UX is the same excellent experience for any number of users.
It is also about business. You don’t want to lose customers because the system doesn’t perform with the 101st customer. Quite often systems scale in a way that they try to give good experience to the 100 first users, and the next one in line gets a message “please try again in a minute”. This sort of queue is good for the performance of the first 100 users but not the others. It could be slow for everyone, too, which is worse for your business. You want to find out how the response time works for the users. Then you can decide if you want to increase the number of intended users, and speed up the system. This is becoming easier with cloud services, and even cost-effective. Each new user of course still costs something but you don’t need to pay fortunes for the extra performance. Each satisfied user gives more business, so the extra money for extra performance pays back.
Performance testing gives you the decision power to make the needed changes to your system. You will know how fast the system is for different types of users, and for different kinds of load profiles. Then you can decide if you want to increase your system performance and by how much.
Modern times are faster than ever. The tolerance of users for slow systems is low. If they have a choice, they will not wait two seconds to go to another provider. This is especially true in business-to-consumer business with lots of competition. It is a bit less crucial if the user really has no choice. But even then the users will complain. And they often complain publicly, in social media. This is very bad for company image. Customers will try to use other companies than the ones with bad image, even if it is difficult. The customer is straightforward. Be lovable, get business. Be annoying, and people will go to extremes in talking about bad experiences and avoiding that company.
There is an easy solution. Performance testing. Doesn’t matter what you call it. Just do it!
