I started my career as a Telecom Engineer for Rational Software in the load testing space back in the late 90s, and when I look back on the last decade, there were enormous advances in the broader IT world including development methodologies, processing speeds, network speeds, mobile devices (it’s hard to believe the first iPhone was only released 6 years ago). But the question is, has the world of load and performance testing really changed all that much? Are the missions the same? Are the challenges different? And how can we be prepared for the future of load and performance testing?
Let’s start with what hasn’t changed:
- Websites crash.
Crashes are a reality today just as much as they were 10 years ago. While many companies have become aware of big events (e.g. Cyber Monday, big ad campaigns) that cause traffic spikes, exact traffic levels are still difficult to predict. One big difference between now and then is the sheer number of websites on the internet. According to Netcraft, the number of active sites on the internet has increased by almost 1000% over the past ten years. More websites = more crashes.
- Developers still think their code is bug-free.
Being a load tester can sometimes come with the occasional power trip that results from crashing an application written by developers who think their code is perfect. While I’m sure their code is very good, load testing can still quickly uncover any flaws in the code or architecture that can cause performance issues.
- Load testing is still pushed off until late in the development cycle.
This is a reality most testers just have to deal with. Testing in general, but particularly load and performance testing are held off until the end of the development cycle, which can be particularly frustrating for testers who can be blamed for holding up a release.
- HTTP is still a connectionless protocol.
Furthermore, it’s being used to drive a world that is becoming increasingly connected. In fact, the vast majority of advances in web technologies (cookies, sessions, AJAX, WebSockets, SPDY, etc.) have been created in order to overcome the HTTP connectionless limitations. For load testers, this means it still causes complications.
What has changed?
- Load testing is becoming a mandatory step in the development process.
I’ve been talking to more and more companies these days that are requiring that all applications go through load and performance testing before they’re deployed to production. This is especially true for new online services who know that they only have one chance to show their best or likely lose that customer forever.
- The performance of applications is becoming more important than the breadth of functionality.
For some companies like insurance and banks, the importance of application performance is much higher than the pure number of functions their apps can perform. This means that load and performance testers are playing more prominent roles within these development organizations.
- The number of technologies built over HTTP is growing each month.
More and more technologies are being developed to make the web faster, more secure and more reactive, and more and more development organizations are adopting them at faster rates. This means load testers are required to test apps containing complex technologies they’ve never seen before, and it’s no easy task to test apps utilizing AJAX, SPDY, WebSockets, video streaming, etc.
- App developers have to consider the performance of their apps on mobile devices and networks.
Morgan Stanley has predicted that mobile internet users will surpass desktop internet users by the end of the year. With this in mind, performance testers need to be able to recreate the use cases and network conditions actual users will experience with several different network types and several different devices.
What can you do to handle the realities of today and be prepared for load testing world of tomorrow?
Don’t avoid load and performance testing.If you’re one of those people who think your apps will be fine and users will do the testing in production, I hope for your sake that your developers actually do write bug-free code. Remember, your end-users will not be as forgiving or as patient as virtual users are when your application is under high load if you recall the old Amazon.com statistic about losing 1% of sales for every 100 ms delay in response times.
Make your tests as realistic as possible.Load testing is much easier these days with the tools available, but don’t think it’s a “point & click” operation. I see too many companies running “load tests” that do not simulate the number of users observed in production nor the conditions under which the apps will be used.
Make sure your load testing tool can match the rhythm of the technical “dance”.Developers and architects are going to want to take advantage of the latest technologies, even some that are still in beta. As a tester, you and your tool shouldn’t be the bottleneck for the product launch. Make sure your tool supports your needs as well as the needs of your development organization.
With all of the advances in web and mobile application technologies and the instant response times end-users expect these days, the performance of applications is only going to grow in importance. My advice to load testers is to stay on top of these trends because they move quickly. It’s certainly an exciting time to be a load tester.