Load testing best practices for DevOps and Agile
Shift left and component testing – driving earlier load testing execution
What’s the upside of faster, increased testing within shorter cycles? How about having the ability to quickly identify a performance problem upstream during development so that you avoid the typical practice of complex/costly post-sprint correction. Load testing earlier, continuously, and automatically is the right approach.
Service Level Agreement (SLA) Management
Conducting load tests earlier starts with proper documentation of user stories, which should always include all associated performance requirements (similar to functional testing approach). This involves identification and documentation of Service Level Agreements (SLAs) and load tests results analysis in relation to performance indicators such as:
- DNS resolution speed
- Response time
- Time-to-last-byte
- System uptime
- The technical behavior of the infrastructure
A good rule of thumb when making sure performance is properly integrated into development work is to put SLAs in the user stories directly, as another dimension in your Definition of Done (DoD). In this case, a user story cannot be “completed” if the performance criteria are not met.
NeoLoad allows you to set custom SLAs. These thresholds are used to integrate load testing into the Continuous Integration process. It will condition a pass/fail test status, determining whether to continue the automatic build process. Learn more about NeoLoad.
Load Testing of Components
Validating code performance at the earliest stage means that testing starts well before the application is complete. Load tests should be run as soon as the most strategic components are available. The goal should be to load test API, web services and microservices representing the application’s life-giving organs.
NeoLoad is designed to make load testing as simple as possible. It is aimed at both specialist testers and developers and allows testing of APIs/components during the early stages of the development cycle.
Service Virtualization for Realistic Component Load Testing
There is an interdependence with which an application’s components interact. Isolated load tests of each component preclude performance validation of an assembled system. As a result, the component testing approach offers two options:
- Wait for the component availability of those consumed by the load test
- Implement service virtualization on components not yet available in order to make load tests more realistic, faster
NeoLoad interfaces with service virtualization tools such as Parasoft and SpectoLabs. Want to learn more? Check out our white paper, Using NeoLoad for Microservices, API, and Component Testing.
Automation of Load Tests and Non-regression Performance Tests
When unit load tests of components are defined, developers can launch them automatically with the Continuous Integration server (e.g., during nightly builds). Build after building; these tests can check the component’s performance trend over time; this is a non-regression performance test.
Using the pass/fail status of the tests, the Continuous Integration server can automatically decide whether the integration process can continue, or if it must be stopped for immediate issue correction.
Since the status definition of a load test is closely linked to SLAs, it is necessary to define them precisely to be able to block or authorize the next steps in the build process.