#websiteperformancetesting

Any website needs to be evaluated against a host of parameters such as stability, loading speed, stability, and scalability under varying load thresholds before it is deployed for actual use. This is of utmost importance as a website with poor functionality and usability can affect its user experience and get rejected by the very users it wants to reach out to. Remember, outages with websites or software can make a big impact on a brand’s popularity as evident in the cases of Facebook, Lloyds Bank, and Jetstar. For instance, on March 14, 2019, Facebook was not accessible to many people due to a server configuration change. Also, Virgin Blue’s reservations management website faced an outage for 11 days leaving many passengers stranded, and the company Navitaire ended up paying more than $20 million to Virgin Blue as compensation.

As per Gartner, the average cost accrued due to IT downtime is $5,600 per minute. And since businesses operate differently, the lower end cost of downtime can be around $140,000 per hour vis-a-vis $540,000 per hour at the higher end. These statistics prove that website performance testing cannot be downplayed or ignored when it comes to understanding the robustness and responsiveness of a website under a reasonable load. So, let us discuss the best performance testing strategy to adopt in order to achieve an optimal website performance under realistic benchmarks.

Best practices for conducting website performance testing 

Since today’s users do not countenance websites with functional discrepancies, it is critical to conduct web service performance testing to validate the website’s ability to meet all pre-defined performance benchmarks. Performance testing can help you determine the speed, responsiveness, stability, and scalability of a website in varying conditions or circumstances, namely, heavy user traffic. The best practices are as follows:

#1. Create a baseline for user experience: A website is not only about responsiveness or load times, but also knowing how satisfied the users are while using it. For instance, a balance must be reached between meeting all sundry parameters instead of just a few. So, decreasing page load time should not be at the expense of stability, as a sudden website crash can throw all calculations out of the window. The performance testing methodology should be holistic and consider the entire user experience instead of looking at just one parameter.

#2. Set realistic benchmarks for performance: It may happen that the expectations for the website are not realistic enough, prompting you to skip certain aspects of performance load testing. However, such an approach can let the website face latency or downtime when subjected to realistic user traffic. For example, an e-commerce website should be robust enough to perform optimally on special days such as Black Friday or Christmas when the user traffic is significantly high. There are innumerable examples of companies facing users’ ire when their websites do not perform during crunch times.

So, it is important to set realistic parameters based on practical scenarios. The testbed should use different devices and client environments to test whether the website performs more or less optimally across device platforms. This is due to the fact that users browsing the website can use any device, browser, or operating system. Further, text simulation should not begin from zero as the load need not always go to zero and slowly rise from that baseline. If at all, such a simulation can give the test engineer a false picture of the load threshold.

#3. Record traffic after clearing browser cache: If the cookies and cache are full during the recording of a user scenario, the browser uses these data to process and deliver client requests rather than dealing with the server (sending data to and getting a response from the server.) In fact, there are specific tools that get a new browser to record tests.

#4. Test early and often: Website performance testing can sometimes be an afterthought and is often conducted in response to user complaints. However, it should be made an integral part of the SDLC using the Agile’s iterative testing approach. Set it up as a part of unit testing and repeat the tests on a bigger scale, especially at the later stages nearing completion. Use automated application performance testing tools as part of the pass-fail pipeline. In this pipeline, the ‘pass’ code moves through the pipeline while the ‘fail’ code goes back to the developer for fixing.

#5. Measured speed vs. perceived performance: Merely measuring load times can be misleading and missing the big picture, for the yardsticks of performance can vary from user to user. The users aren’t only waiting for the website or application to load but want it to respond to their requests. And to know how fast users can get responses (read useful data) to their requests, include the user processing time as an element in measuring load times. Here, the tester may push the processing work from the server to the client, which can make pages to load quickly from a server standpoint. However, forcing the client to process extra can turn the real load time longer. Although pushing the processing to the client need not be a bad performance testing approach but the impact on perceived speed should be taken into account as well. It is advisable to measure performance from the perspective of an user rather than from the server.

#6 Build a performance model: Performance testing should include understanding the website’s capacity and planning its steady state. This can be in terms of the average user sessions, the number of concurrent users, server utilization at the peak period, and simultaneous requests. Also, suitable performance goals should be defined, such as maximum response times, acceptable performance metrics, system scalability, and user satisfaction scores.  

Conclusion 

It is not enough to provide the results of performance testing, for the next step should be to triage the system performance and reach out to all stakeholders; developers, testers, and people manning operations. So, the key to any realistic performance testing is to take a broad view - infrastructure for realistic testing, tracing errors to their source, and collaborating with developers.

Resource

James Daniel is a software Tech enthusiastic & works at Cigniti Technologies. I'm having a great understanding of today's software testing quality that yields strong results and always happy to create valuable content & share thoughts.