Complex problems often have simple solutions. But when we look at our performance-testing space, many of us dream too much instead of taking action. This blog post introduces you to a few simple ways to achieve better performance. These are easy to implement, but still require a lot of commitment and forward- thinking. And always remember—you can’t improve performance by testing.
Test early
Neglecting this task is the number-one pitfall. You may have great software designs and your developers may have spent months on the implementation. The top priority in the daily scrum meeting is the functionality and the integration to other third-party services. Not a single non-functional story is present in the backlog. Despite all that though, the response times, error rates, scalability, and reliability are, for some reason, all missing from the requirements. I’ve seen many such development projects, including some with agile or scrum teams—they are no exception to this pattern.
You can easily reverse a downward trend in performance. Challenge your architect or business analyst and ask for performance requirements. Focus on the most frequently used business cases or services. The top 10 is good enough to start with. Check with your developers which unit-level tests are in place. In some cases, cucumber-based tests can be reused for performance testing.
You’re a performance engineer, after all, so it’s your job to open up the minds of your developers to early-performance testing. There’s no need for you to implement all the cases. Just provide guidance and ensure the developers can run scaled-down performance tests by leveraging the tool-set they already know.
Test often
How often do your developers and performance-testing teams utilize their test sets? Executing this testing and then deploying the new product to production is often the preferred approach. Obviously, there isn’t enough time to fix the issues identified as the agreed go-to -production date is just around the corner. In such cases, project leads and decision makers have to go ahead and take the big risk of moving on to production without having addressed performance issues at the start.
A better strategy for dealing with any last-minute hotspots is to make performance testing part of your engineers’ daily work. Performance testing for continuous delivery is a great starting point. I highly recommend that you increase your performance-testing coverage in the early development stages, and make sure this testing is executed as part of the daily schedule. Ideally, you should facilitate an automated-performance gate within your build pipeline. The result will be a win-win situation for the entire team. The continuous performance baseline and the automated results reporting will help to bring the crucial performance metrics into full view of your developers. With frequent executions of automated-performance tests you can identify hotspots much earlier and fix these problems much more easily because the recent code changes will still be fresh in their minds.
Test the right things
Load and performance testing won’t help much if you choose the wrong test scenarios or user-simulation approach. API-based testing is powerful and there are many reasons why we should all use it. But trusting in this technique alone will be of little use if you ignore how your customers are using the new application.
Your approach to performance testing needs to reflect both the way your customers are using the new product and the frequency of business cases or services. Merely selecting the cases that are easy to automate is a waste of time. Effective performance engineering focuses on the scenarios that are key for your customers. You can derive usage volumes from your performance requirements or production monitoring tools. Alternatively, you could apply a methodical approach such as Little’s Law. Once the number of TPS and concurrent users are calculated, it’s a good idea to get in touch with your business analysts to understand how the application is used by their real users. Peak hours, the most frequently used functions, devices and geographical locations can all play a very important role. You can’t afford to ignore them in your performance-testing strategy.
Happy performance testing!
コメント