Performance Testing of Web Applications: So Much More than Running a Script - Igor Samokysh
Did you ever abandon a web page that took too much time to load? You are not alone. One in four people will abandon a page if it takes more than 4 seconds to load. Moreover, each additional 0.1 seconds will reduce sales by 1 percent!. This will, of course, have a huge impact on your business model.
A common risk mitigation strategy for this problem is to do performance testing of your application. So, what do you envision when you hear the term performance testing? You probably think about throwing hundreds or even thousands of emulated virtual users against your system and keep ramping them up until it finally crashes. But haven't you felt that there is something wrong, not only in your system but in the process of how you approach the problem? You start with attacking the server with Jmeter and end up with some messy graphs that give much value to you or to your team or stakeholders. Then you leave the script, declare performance testing done and report results. Don’t you think that there is something missing? Probably the process of doing performance testing was not straight, consistent or clear on its objectives? At least that was true for me.
So, I will present to you a 7-step methodology for doing performance testing of your web application which helped me to do it in a coherent and structured way, erasing a lot of potential pain. One of the problems I am still struggling with is the time for implementation. Each time I seem to spend significantly more time that was initially estimated.
My methodology starts with identifying the test environment and ends with analysing and reporting your results. In between, there are more activities, like figuring out goal speed, who should define it and how to design and implement the tests. At the end, we will visit some biases and myths surrounding performance testing.
- core activities to implement performance testing methodology
- myth surrounding performance testing