What is continuous load testing? Where does it fit into DevOps? And, perhaps most importantly - why should we care?
If you’ve been following the continuous testing movement, you’re already well convinced that testing needs begin earlier, and play an integral role throughout the DevOps process. But what about load testing? Even before implementation begins, teams should be thinking about and planning for performance requirements. On the flip side, performance is very much part of the conversation in response to operations and monitoring activities.
In this sense, load testing is not something that can “shift left” or “shift right”. Load testing is fractal in nature, and should be integrated at all stages within the software development lifecycle. That’s how we end up with Continuous Load Testing.
Performance in an application is typically viewed as a “system issue”. But leaving load testing until production is just as dangerous as leaving functional testing until production. By load testing earlier, we can understand and dissect performance at the component level , which is an easier, highly repeatable way to test. Sound familiar? It’s the same concept as unit testing and API testing. The earlier you find the problem, the easier it is to de-bug.
But load testing later in the DevOps cycle is equally important. This is when you can get a feel for overall system performance, and can tackle production-sized problems around availability, scalability, and reliability. This provides valuable insight into production behavior, and can help validate the risk mitigation load testing you did earlier during development.
Load testing helps you avoid performance issues—and much more
Load testing helps you avoid four types of risks:
Performance
Performance is a very loose umbrella term for a whole range of measurable application metrics. These metrics can start with page load time and span all the way to numbers of concurrent users, origin of page components, browser caching, amount of page views per minute, and more.
Availability
Availability, simply put, is the infamous HTTP 503 page. These issues are among the worst dimension to experience as a customer, and therefore are a high priority in load testing.
Reliability
Reliability metrics are essentially asking whether your application returns the expected response. Reliability issues are long and exhaustive and can be difficult to uncover in scripted scenarios, making exploratory load testing a great way to delve into reliability issues under load.
Scalability
Scalability covers aspects ranging from scaling up or down infrastructure in response to unexpectedly increased workload, to simply knowing if your infrastructure is correctly scaled for your day-to-day operations. Long wait times, reduced services, incomplete transactions all have the knack of driving up customer angst.
Load testing is everyone’s responsibility
Load testing has long been the domain of performance testing specialists for a reason: it’s difficult. But in the quest for Agile and DevOps, organizations are realizing that all the practices associated with software development and testing need to be reassessed, including load testing. If load testing is a crucial part of the entire DevOps cycle, everyone needs to have load testing on their radar. It’s as simple as that.
To make that possible however, there needs to be a solution that makes load testing accessible to everyone. And that’s exactly what we are trying to accomplish through developments like Tricentis Tosca Load Testing and Flood Chrome: reduce the complexity traditionally associated with load testing to give developers and testers a fast, feasible way to get immediate feedback on how code changes impact performance. With this new “lean” approach to load testing, any developer or tester can get started with load testing.
Learn more in this webinar with Tim Koopmans on Continuous Load Testing.