How to Perform Load Testing With Real Browsers Using Flood Element?

So, you’re thinking of load testing.

Maybe, you are frustrated with current solutions you are using and finding that it is too difficult to write and maintain your tests.  Or maybe, you are thinking about doing load testing for the first time. Either way, it’s a great first step to be thinking about load testing at all – many companies don’t and suffer the consequences.

There’s an established link between app performance and essential business metrics, such as revenue, customer signups or more general customer satisfaction. All companies that do business on the web should want to ensure that performance doesn’t negatively impact these key measures. Even when these measures are improving, you might find that the app could run better to consume fewer resources, saving you and your user’s money along the way.

Whether you are brand new to load testing or have experience in the field, you are likely aware of the dizzying array of tools and approaches available to get the job done. Today I’d like to tell you about my new favorite load testing tool – Flood Element.

Many popular tools operate at the protocol level – they attempt to approximate users’ behavior on your app by issuing network requests. However, in today’s world wide web, web apps are becoming more and more sophisticated as well as utilizing many more of the browsers’ ever-growing list of features than ever before.

Even seemingly simple apps like an online shop use a plethora of browser features to make the experience of choosing items, ordering and paying online as smooth as possible for the user.

And so, in this modern era of the web, protocol level user (PLU) testing can only give us so much of the picture of our app’s performance. By contrast, new tools like Flood Element test by simulating user behavior using real web browsers. We call this approach Browser Level Users (BLUs).

In Flood Element, simulated user behavior is defined using simple, natural actions such as clicking links and buttons, filling in web forms and so on. Once you’ve defined the behavior, it’s a snap to run at a huge scale at flood.io – and by huge scale, I mean thousands of users and from all over the globe!

Load testing with Flood Element can help you develop a holistic, intuitive view of your app’s performance as experienced by a user. Given that thinking as users are what we all naturally do when we’re users ourselves, it’s also significantly more comfortable to get started with an Element BLU test than with traditional PLU tools.

The holistic view

Using Flood Element to measure performance on your whole app from users’ perspective is a great way to develop a holistic view of your app’s performance and thus defend against unexplained changes – be they temporary anomalies or perhaps regressions in the code.

Flood Element BLU tests provide a view of performance much closer to the user experience. They take into account every part of a performance that a user will experience: network performance, but also on-page script performance as well as third-party scripts such as analytics or advertisement add-ins (in fact our tests are so realistic that you need to take steps not to create false data in Google Analytics.)

If running a BLU load test with Element gives you a holistic view of your app’s performance a point in time, running tests regularly allows you to build up an intuition of whether your app is getting faster or slow… perhaps suddenly as in the signup widget scenario.

Writing a test

Now let’s see how easy it is to get started with Flood Element.

Element scripts are written in TypeScript or modern JavaScript. For the best experience, we recommend using the remarkable combination of TypeScript edited using VS Code because it gives you a lot of useful assistance in developing your tests.

You can install Element using the getting started instructions here: https://element.flood.io/

Once installed edit and test your script locally, and when you’re ready to upload it to flood.io to perform a full-scale load test by signing up for a trial here: https://flood.io/load-performance-testing-tool/free-load-testing-trial/

A basic Element BLU test for the signup scenario above might look like

If you’re familiar with testing at the protocol level, you know that all timings are arranged around request-response transactions. When learning to test at the browser level, there are a few extra subtleties to take into account when finessing your tests. In particular, there are no real built-in timing groupings, so we need to introduce our own in the structure of our test.

The most straightforward approach for grouping timings is to wait for the necessary elements to appear on the page — just like a user would.

From the scenario above, we’re interested in timing the user experience of signing up, but not so much the loading of the page. So, in the first step, we visit the URL and wait for the page to reach a known state — until the title is shown.

Next, we act we’re interested in keeping an eye on, namely filling in and submitting the signup.

Now it’s time to save the script locally, so we can upload the script to Flood and run it with hundreds, or even thousands of concurrent users.

• (If you haven’t already) sign up for flood.

• Create a project

• Click the “create flood” option in your new project

• Create your test using the Flood Element Option

• Name your test

• Upload the .ts script you have created:

• Set the number of browsers (users) as well as # of regions to get the total # of users (# of browsers * # of regions).  Also, don’t forget to set your test duration:

• Launch your test and wait for results to come in:

• Once results are in, view your graph and jump into any problem areas they may highlight:

Conclusion

So now you know why (and how) how to test with Browser Level Users using Flood Element.  With this new approach, we’ve eliminated a lot of the pain of creating load tests, and we’ve also made the results more realistic at the same time.

It may seem daunting to get to testing with thousands of users, but it’s easy to take each piece one step at a time:

1. Download element
2. Write a simple test locally, covering your key scenario (i.e., checkout)
3. Run the test locally with ‘element run’ to make sure the test runs completely
4. Upload your test to Flood and run with 5-10% of your max load (i.e., if your max load is 5,000 users, start with 250-500 users)
5. Assess the results and tweak your script and app as needed
6. Upload your test to Flood and run with 50-100% of your max load (i.e., if your max load is 5,000 users, then run with 2,500-5,000 users)
7. Increase your test coverage to cover the additional scenarios needed, until you achieve the test coverage you desire.

Depending on the complexity of your test scenario, you might be able to get up and running with thousands of users in under a day.  So don’t waste any time – head on over to https://element.flood.io to get started experimenting with Flood Element today!