Everywhere you look, people are evangelizing the benefits of fast feedback on code commits. 86% of teams automate their functional regression testing to make sure they get feedback on every build. The idea of continuous testing is clearly a well received one when it comes to seeing whether the application meets functional criteria. Yet, only 29% of teams have implemented automated load testing for those same applications.
Why Load Testing is Often Overlooked
As we interact with companies looking to elevate their load testing on a daily basis, we keep a pulse on some of the main reasons why load testing is lagging behind regression testing. Generally, the top 5 reasons we hear consistently are:
- Not enough time to load test: current load testing tools may require days of scripting to create a robust and reliable test script, and getting an adequate set of servers to run a test may take weeks or months
- Not enough understanding of how performance impacts revenue: misunderstanding that functional bugs impact revenue more than performance issues
- Tests are too expensive to run: commercially licensed tools are too restrictive and costly to allow for frequent measurement of performance
- Tools are not easily adopted or understood by wider team: current performance tools require dedicated experts and cannot be easily picked up and used by all team members
- Performance issues aren't binary and can be more difficult to detect: functionality either works or doesn't, but determining a performance regression can fall into more of a gray area
What You Can Do to Make Load Testing A Top Priority
Changing the team mindset from one that has largely ignored performance to one that thinks about it proactively doesn't happen overnight. However, there are some quick wins that can be implemented to get your team thinking about continuous load testing as a habit:
- Remove unnecessary wasted time in the load testing process: new tools can reduce scripting time dramatically by creating load via the browser rather than more complicated protocol level testing. Check out Flood Element to see if you can cut your scripting time down from days to hours
- Share the impact of performance on revenue: if you can create your own metrics on how poor performance has impacted your top line revenue, that is ideal. If not, there are plenty of resources about this online
- Use the cloud to reduce infrastructure costs: current stats show that the majority of companies are doing at least some cloud load testing. Load testing in the cloud can reduce the number of fixed costs for executing a load test.
- Use tools the whole team can understand: open source tools like JMeter and Gatling are typically more accessible and adopted by developers and testers in a scrum team.
- Understand what to look out for in your load tests: make sure everyone on the team understands the key metrics to look out for in your load tests so you can easily identify when a potential performance regression has occurred.
Go Forth and Load Test
Load Testing has typically flown under the radar, but those days are long gone. Performance is now the lifeblood of both internally facing and externally facing applications, and the risk of overlooking performance is too high to ignore load testing any longer. Luckily, the tools required to do this job are becoming much easier, and practices around continuous load testing have matured significantly in short time. So don't let excuses prevent you from getting this mission critical feedback, and start your journey towards continuous load testing today.