Traditional Load Testing Is Dead. Here’s What’s Next

So, this is one of those posts that almost angers you when you read the title, but then, you get a bit further down the post and realize, “oh my god, that is true… what do I do now?”. Think about it — yes, we now have recorders, but how effective are they at capturing the interactions we need to test and helping us move more efficiently?

I’m not a huge fan of making myself feel old or outdated, but in the last few months, I’ve realized how old the load testing space is. The first load testing tools were released in 1993; the first recorder was released around 2011, and even still, there have been few innovative releases. But that is nothing in comparison to the functional testing market or the performance monitoring space.

Think about it — yes, we now have recorders, but how effective are they at capturing the interactions we need to test and helping us move more efficiently?

We still have to manually script the tests, make edits to account for dynamic content, and ultimately spend a lot of time trying to tweak the tests so that they will playback properly and run at scale.

Here’s why traditional load testing is dead:

• It’s Inefficient: It takes too much time for testers to create and correlate a load test, which creates a bottleneck earlier in the testing process. If there was a way for testers to create tests faster, they could run more tests and spend time analyzing and optimizing based on the test results rather than getting hung up in the creation process.
• Fake Browsers = Fake News: The ultimate goal of load testing is to ensure that your web performance can stand up in the wild. Why is it then that we’re still testing with emulators as opposed to testing right in the same browser as our users? It’s no shock that even a very good replica is still a replica. There will be inconsistencies in the behavior of an emulator vs. a real browser, and there will be variances from emulator to emulator. Ensuring that you’re testing with the most accuracy becomes a challenge, and there are always scenarios that work in load tests and cannot perform under similar conditions in production.
• Lacks Actionable Data: In most cases, the test results yielded from every load test have to be translated, repackaged, and sent to your dev team to implement changes. Not every team has the time or, honestly, the energy and priority to spend additional time reworking the data they get back from their team or their counterpart teams. But what if we could get browser-based metrics that every team could understand and leverage for improvements?
• Not Agile/DevOps-Friendly: Traditional tools were (and still are not) built to support fast-paced, lightweight teams looking to run as efficiently as possible.

So, What Now?

If teams want to move faster, test with accuracy, and remediate issues quickly, the tools that support these teams need to change. To do this, teams will:

• Prioritize making test creation faster and easier

• Ditch emulators
• Automate and add CI/CD flexibility
• Integrate with the tools they rely on

Here’s how you can start reviving your load testing processes to run faster without sacrificing accuracy:

1. Create realistic load tests without writing a single line of code
2. Load tests in real browsers at scale
3. Automate tests
4. Debug in real time

Don’t get left behind in a world of legacy tools — take the first steps in revamping your testing processes.