Performance Testing in a Dynamic World
In many fields such as finance, engineering or politics there are groundbreaking changes ongoing. However, our human skill to adapt to new situations will help us to deal with this disruptions.
In this post, I will shine a light on challenges in software engineering, more specifically, on load and performance testing in an energetic environment.
What are the difficulties we are facing?
Over many years we’ve planned performance tests in advance. Requirement engineers documented non-functional aspects. Software developer designed and implemented the new system with the requirements in mind. Finally, testing teams verified and validated the requirements and hand the new product over to operation teams.
This stage-by-stage approach disappears more and more in an agile world. Nowadays, a single team is responsible for design, implementation, test and operation of the new product. Excellent collaboration is fundamental to the success of teams operating in this mode. When it comes to load and performance testing the biggest hurdles are time constraints, the frequency of changes and the often just partially available system under test.
What are the pillars of a dynamic performance testing approach?
First of all, you need to work on your application and environment monitoring. If you are not able to capture all transactions on development or production stages, you’ll loose too much time with troubleshooting. Ideally, you integrate a real user, application performance, and component monitoring and you share all metrics with your project members.
Secondly, implement and continually execute service based performance tests. Even if your new system is not completely integrated, it makes sense to evaluate response times of your new services under multi-user load conditions. Provide results of those tests in online dashboards and grant access to the whole team. Set thresholds for your most important performance metrics such as throughput, error rate, response time and clearly communicate any violation.
Finally, don’t forget end-to-end performance tests of the fully integrated application. While service based tests are required to find issues in early stages, the E2E test in a close to production like environment is a final validation and utterly required.
Don’t forget that performance engineering is more a journey than a destination.