NeoLoad enters the world of end-user experience testing

NeoLoad enters the world of end-user experience testing
3 January 2023 Youssef BEN ALI

‘By David Boxall’

What is NeoLoad’s new feature?

With so many testing tools which have been well-established for a long time, it is rarer nowadays that they unveil new major features. This time, however, Tricentis announced RealBrowser for NeoLoad and I thought it was well worth looking into.

Traditional NeoLoad scripts will test individual APIs and page resources, but these don’t necessarily equate to the real user experience. JavaScript execution and loading the DOM can mean a user is still waiting to use the page, even after the resources have been called (see our blog post on browser-based performance analysis for more information).

Like Selenium, you can now create transactions by telling the browser to click on buttons, type text into the browser and wait for elements to load. No need to mess with regular expressions and correlation – what could be better?

How does it look?

Like many others, I have used TruClient as a built-in part of LoadRunner. Also like many others, I found it a very confusing experience, to begin with. The tool looked completely different from the rest of LoadRunner, and I found myself watching YouTube tutorials within an hour.

But with NeoLoad it’s different. You record a script with the same recorder as always. You select the actions from the same Actions section you know already. You check it runs with the familiar Check User Path. It feels completely integrated and just like an extension of the standard tool – just as it should be. You can even add a RealBrowser population to your existing API test scenario without doing something special.

RealBrowser is now added to the

Recording options

Okay, the object definitions are handled a little differently, but I didn’t expect them to be the same. To type some text into a textbox you need to brush up on your XPath or CSS selector skills. Although NeoLoad will try and help you here by automating it during the recording. I found this worked with mixed results, sometimes producing a complicated XPath which breaks when using a different user.

RealBrowser actions can be added into any script

What about debugging?

For me, the real test was how easy it is to debug. The design might be simple but if replaying the script turns into a nightmare, then does it matter?

To be honest, the first couple of attempts did not go well. The browser loaded and did a single button click before returning a blank white page and crashing. Not a good start!

Using the age-old performance tester technique of restarting the application seemed to do the trick though, and since then I’ve had no issues. Whilst it runs, you can see the selected elements highlighted in red, screenshots are saved for each step, and you even get a copy of the page response saved.

Replaying a RealBrowser action shows additional sections to help with debugging

For me, working with XPaths is never a completely fun experience (the discovery of iframes and shadow DOMs during a recording will always cause heart palpitations) so I didn’t expect writing scripts to be straightforward. However, this is just part of the deal using these technologies and despite that, using NeoLoad for this has felt very simple and logical to do.  

So, what are the limitations?

Of course, no testing tool is perfect. There are some options which aren’t available and some limitations which don’t surprise me – let’s look at some of the key points in a quick summary:

  • Recording is only possible on Chromium – other browsers are not supported yet. This uses the latest version of Chrome at the time of their release. This does not give much flexibility if you need to control which version is used.
  • ° When it comes to playing back your script, then you can use other versions of Chrome, Firefox, or Edge (more information is available on the official documentation).

  • Mouse hover interactions are not recorded (but you can add them manually with action later).
  • There are only 2 selectors available – XPath and CSS. Selectors are a key concept in these scripts, as we use them to identify the elements which we interact with inside the script. TruClient has 4 different types, including the very handy JavaScript option (which most people are more familiar with). In comparison, RealBrowser feels limited here.
  • ° It also makes it impossible to handle shadow DOMs, which cannot be selected with either of these methods.

  • Only basic authentication is supported. If your application needs certificates, then RealBrowser is not an option for you.
  • Like most browser-based testing solutions, the resource overhead (memory utilization and CPU consumption) is a lot more expensive when compared to traditional API scripts. At Altersis Performance, we have benchmarked similar tools to RealBrowser and plan to share our findings in a future blog post – watch this space!
  • Final thoughts

    Overall, this is an impressive first release from Tricentis. Whilst there are still some limitations, I have no doubt that it will improve in the upcoming versions and we’ll see more functionality developed.

    I really like the recording process and the ease with which a script can be designed and added into an existing test set. There are already quite a few RealBrowser actions provided, I’m looking forward to trying more of them out in the upcoming weeks. RealBrowser has a lot of potentials and is a feature to keep a close eye on in the future.


    Leave a reply

    Your email address will not be published. Required fields are marked *