In part 3 of this article we have observed the strategies for making sure that user data does not get modified or deleted accidently. In this part, we will discuss strategies for avoiding performance issues.
Generally when an application is being used by a large number of users, the performance of the application deteriorates. This happens because the computer server on which the application is hosted has limited processing capacity. When number of requests for pages becomes large, processing capacity of the server machine becomes a limiting factor and thus performance of the application starts deteriorating. This results in conditions like unusually high time required to process page requests, events (press of a button or clicking on a link etc.) taking inordinate amount of time etc. In extreme conditions, the application becomes unable to take page requests and thus users do not get the requested pages at all or requested event (press of a button or clicking on a link etc.).
To see if performance of the application is reasonable or not, the testing team may be doing performance tests on the production instance to see if the application is available to end users and that users are able to use the application effectively even in high load conditions. To do this, they generally employ automated scripts. These scripts create virtual users. These virtual users do various kinds of transactions on the application. To simulate actual conditions, a large number of virtual users do these transaction simultaneously so that a high stress level is created on the server machine. This stress level and performance of the application is recorded by the script. When the testing is complete, this recorded performance results is analyzed by testers to know if the application performance was good or bad under those stress conditions. Based on this report, some tweaking of the application can be done by the development and support teams so that performance of the application can be improved. These tweaking include increasing processing capacity of the server, reducing page sizes to load them faster, tweaking database queries so that data retrieval from database can be faster etc.
When testers do performance testing, they create one problem for actual users of the application though. When the script creates virtual users and these virtual users do a large number of test transactions simultaneously then the application is really under stress and if any actual user tries to access the application then he will experience poor performance. The script may take 30 minutes or more to run depending on number of transactions to be checked. During this period, the application will not be fit for use by actual users. But no organization may allow its application to be down for so long. Then how testers will do their job?
Some strategies can be taken to alleviate this problem.
- The performance testing can be done at off peak hours. For example in the night.
- The performance testing should not employ a large number of virtual users. Instead performance testing can be done with only a fraction of number of users and the results can be extrapolated for larger number of users. For instance, we can do testing for 500 concurrent users and extrapolate the results for 5000 users.
Once these strategies are in place then performance testing will not a nuisance for actual users of the application.
In part 5 of the article, we will see strategies for security.