Load testing can be a struggle. Many companies grapple with how to test their applications using protocol-level users (PLUs).
Since the inception of load testing, the approach has been mostly the same: simulate the traffic of an application by creating load at the API, or protocol, level. This approach made sense at the time, as we were constrained by a number of factors:
It is not a surprise that PLUs have been the de facto standard in the past. However, changes in the software industry have begun to alter the perception of PLUs in the market.
Though PLUs have been the standard, the lack of resistance is mostly due to the absence of solutions that are easy to use. It doesn’t mean testers don’t frequently strugge with protocol-level testing.
The skill set is too specialized, and not like other familiar tools and languages they are used to working with. Tests break too often, and teams are caught in a constant maintenance cycle and greater test coverage is impossible to achieve. Simulation via API level also does not provide an accurate depiction of true browser performance, and it may not trigger all the components of an application.
But there have been big market shifts in the industry recently that make load testing with browser-level users (BLUs) more feasible:
Leveraging cloud infrastructure and headless browsers allows us to test with real load and measure true user performance. With faster and easier load testing, you can expose critical performance issues earlier in the delivery pipeline—meaning issues will be discovered by your testers, not your users.
Kevin Dunne is presenting the session Continuous Load Testing for DevOps at Agile + DevOps East 2018, November 4–9 in Orlando, Florida.