Performance testing for digital transformation

Bruce Zaayman, Director, Inspired Testing, talks about the evolution of performance testing in a 24/7 world.

---

The perception of performance and speed from the user’s point of view is what drives the quest of performance testing. It’s as simple as this: we know how quickly we’ll leave an app or a site if it doesn’t work. Even with this knowledge, though, it seems that in many quarters, performance testing is still considered a reactive process, something that’s done after a system or Web site is built as a way to troubleshoot problems and make things ‘work better’.

But I’d like to suggest that performance testing, in this very traditional definition of the term, also has the capability to be enhanced and bolstered, to boost your competitive advantage in a highly mobile, 24/7, 100% digital world, says Bruce Zaayman, Director, Inspired Testing.

While there is certainly a case to be made for the role of traditional performance testing, it can be a stop-start process. This doesn’t always make sense in an agile environment, where new builds and features are added almost hourly, let alone daily. Ironically, agile is also a reason performance testing sometimes takes a back seat: it’s not easy to test something when the goalposts are continually shifting.

This is why we have to stop and rethink the entire concept if we’re going to use performance testing to our advantage – to build faster Web sites and e-commerce engines and transactional environments that not only perform optimally, but do so while serving tens of thousands of simultaneous users.

The best way to do this is to focus less on the systems and more on the results. How do we want our systems and Web sites to function? What metrics can we use to measure a satisfactory user experience, rather than just pointing out potential pitfalls? It’s a subtle shift, but a shift nonetheless, and requires not only testers, but also engineers and performance experts to get us there.

What’s more, the evolution of traditional performance testing, and the tools we need to make that jump, are already here and waiting for us.

I’m not talking about ‘new age’ next-generation technology either. Take NeoLoad, for example, which happens to be the continuous performance testing tool we already use extensively across all our client sites in the UK and around the world. The focus here is on ‘continuous’, because that’s how we must approach performance testing if we expect it to deliver performance-driven results.

But even continuous performance testing is not enough on its own. We need to be able to deconstruct what it is that clients want their systems to do, from their users’ perspective. Load times, response times – the way information appears on a Web page and how soon it starts to appear – these are all intrinsic parts of the human experience that can’t be measured with traditional tools.

We may be able to simulate how stable a server will be under extreme load, but can we say how quickly the first lines of text appear on a page when the user clicks it? Users don’t care how many other users are online at the same time, only about their own individual experience. The secret is not only to enhance speed in reality, but also to enhance the perception of speed. So, part of the performance testing evolution is engineering how Web sites are coded, getting text to appear before graphics, getting the first line of text to appear within a second, and making sure text and graphics are continually loaded as the user interacts with the page, keeping them engaged for longer.

This very idea is what tools like Lighthouse are made for – open source, diagnostic tools designed for the sole purpose of auditing the quality of Web pages, with scores for performance, SEO, accessibility, best practices and its level of progress. It’s not rocket science either; for example, you can run Lighthouse in Chrome DevTools, from the command line, or as a Node module.

You can use any of the top Web performance tools against any Web page, like we did for globally renowned shoemaker Jimmy Choo. Working with a Web performance expert, we utilised a selection of tools to create a highly responsive Web experience for the company, worthy of its premium brand.

Web performance is an art on its own, where we look at the code within a Web site and how it can be optimised. We call this our Inspired Performance Testing methodology and it demonstrates, without doubt, that taking performance testing to the next level in our highly mobile-centric digital world is where the future lies. We have the means; we just need to shift our way of thinking and start using these very important and very useful tools as part of our existing processes.

The evolving industry of digital banking is another perfect case in point for optimal user experience. Banks like Monzo and Revolut are built on the premise that the traditional rules of banking are being turned on their head. Now, the customers – the users – are in control of their own destiny, and if they don’t like the rules of engagement, they can go elsewhere at the click of another app. Three seconds is all it takes for impatience to set in. Perhaps the site is broken, they think, as they grumpily log off. Let that happen a couple of times and your customers will be out of there – permanently.

If the above makes you think that new-age performance testing is far more complex than the cookie cutter approach of old, that’s because it is. There’s no one-size-fits-all when it comes to digital transformation, and the same goes for performance testing. As developers and testers, we are beginning to realise that continuous performance testing at the DevOps and API level is more important than signing off a system that can withstand short bursts of extreme traffic. We have to balance the needs of the client with the wants of the user; it’s no good to us or the client if we deliver a rock-solid system to a digital bank that haemorrhages users to a competitor because the user experience is less than ideal.

Yes, the usual performance testing suspects are still relevant. Capacity testing, load testing, volume testing, stress testing, soak testing and spike testing all fall under the performance testing umbrella, as does identifying bottlenecks and breaking points – and they’re all important. But they’re not enough. We have to ‘shift left’, to start performance testing much earlier in the development cycle, and continue long after the system is delivered, to take user experience into account.

Performance testing should be part of our daily sprints, and with the right tools correctly implemented, it becomes easier and simpler to find user paths to track and optimise UX. Ultimately, going beyond performance testing becomes a client retention strategy. If your site or app isn’t responsive, fast, usable and stable, your clients will switch to your competitors, and once they do, they will be gone forever.