Lessons Learned in Performance, Stress, and Volume Testing

Member Submitted

of an actual end user, I’d recommend that the automated scripts be constructed and developed in exactly the same manner in which an end user would execute a business process in the production environment. And second that the test engineer’s utilizes the "think time" feature from the automation tool that allows the automation tool to playback the script at the same rate at which the script was recorded. Furthermore, if the “think time” feature is not available the test engineer can artificially delay the execution of the script by introducing artificial wait times within the test script. The objective is to playback the script at a rate that is similar to the way in which a human being would execute a business process in production and thus emulate throughput with the same number of emulated end users as the total expected number of production end users.

Not testing the entire round trip
Sometimes projects will test an application’s response time at the back-end level only. But what about the interaction between the end user and the application through the GUI or the client side of the application, shouldn’t this be tested too? The answer is unequivocally yes; the response times starting from the client side should be tested too.

The application's entire response time round trip starts from the client side where the end user works with the application. The end user does not work with the back end or the database. Hence the test engineer should ascertain that the end user would have adequate response times from the application from the point in which the end users interact with the application.

While ensuring that the application has satisfactory response times at the back end level it is equally important if not more important that the end users or customers working with the application will also have adequate response times from the client side (GUI) of the application.

Missing Personnel
I can recall one project in which a performance/stress test was conducted while many of the supporting personnel were working remotely or on-call. Key support personnel that were not present at the site of the test. Within this project an in-house developed bar coding application was tested for performance, volume, and stress testing during the middle of the night.

The application worked fine for an initial load of emulated end users but the application under test encountered all sorts of problems when the number of emulated end users was gradually increased. Many of the problems resided with the fact that the application under test needed to have some obscure parameter enabled that to allow the concurrent log-on from multiple emulated end users to the application from the same desktop. The personnel at the testing site did not have an iota of a clue as to how to fix the problem or enabled the parameter since they were not the developers of the bar coding software. The testers on site attempted to reach the developer who created the bar coding application but the developer could not be reached by pager for a long time and when the developer was finally reached a resolution could not be identified remotely for the problem at hand. The result was that the testing had to be halted completely for the night wasting much time and billable hours for contractors.

A better approach is to have all personnel associated with the testing present on site during the entire test.

Absence of a Contingency Plan
The best test engineers can crash an application or bring down the LAN when conducting a stress test since stress testing is

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.