Performance testing for Web-based applications

BANGALORE, INDIA: Websites, such as business portals, are generally used by registered user communities where users login, perform various activities of a business process, and subsequently log out. Generally, these business processes are performed by a single user end to end. There could be many different user types, for various business processes.

However, once a user logs into a particular user role, the user is expected to complete all the activities before he logs out. Within this type of process flow, generally there is no need to bring in another role.

On the other hand, online sites involved in such activities as insurance claim processing, banking processes, account opening and other processes in the financial domain require multiple roles to complete a business process.

This means a process might originate with one user role and then be passed on to another role for the next activity and so on. This process is generally called a workflow scenario, where multiple roles are involved within an end-to-end business process.

Performance testing for Web-based applications generally falls into two categories, single-user business process and multi-user business process (also called a workflow process).

A single-user business process requires one-time authentication followed by a series of defined activities. For example, a user, after logging in to a banking portal, performs different kinds of transactions as an activity and after completion of the transactions logs out. Similarly, a registered user booking tickets through an online site searches, selects, confirms and purchases a ticket.

In both these examples, the user type remains the same across the process. The following diagram indicates the single user scenario where a user logs in once, performs several repetitive activities and finally logs out.

The scripting approach for testing a single user scenario is to simply cover all the performance-critical processes by assigning respective user roles. When the scripts are replayed with multiple users, the load is simulated from the end user perspective. Once a user logs in, he performs all the tasks till the end. He might repeat some tasks with multiple iterations, like searching for a product, selecting a product, and other appropriate tasks. At no point within a specific process flow does the user role change and there is no need for additional user roles to be covered. This type of business process is generally applicable for user-driven applications.

For workflow-based business processes with involvement of multiple roles, the scenario is quite different. In such business processes, there can be multiple roles involved within a process. This type of process is mostly seen in the back-end processing for administration tasks where each business process step is performed by different users with different responsibilities.

Typical applications where different user roles are involved include insurance claims processing, banking administrative processes, account openings, dispute processing, etc. These types of business processes are called “Workflows”.

Here, the business process starts with one role performing a task and passing it on to the next role and so on. A good example of this is in account opening, where a new account application may be submitted by one user, and then others with different responsibilities will be given tasks of reviewing materials, performing validations or lookups, and finally entering approvals. 

In the conventional approach for scripting, the script starts with Role 1, logs in, performs the tasks, and logs out.  The script then goes on to login again as Role 2 or Role 3 according to the flow and continue logging out and logging in for different user roles. The frequent logging in and logging out will result in a huge number of hits to the application when thousands of users are involved, resulting in undesirable performance degradation and unrealistic testing. Thus, the conventional approach becomes impractical.

The Service Level Agreement (SLA) only governs the release of one work from one role to the other. At any given time, there should be an adequate amount of work available for each role to perform, as in a real office scenario.

In a typical work place like a bank or insurance company, there will be many processes and it becomes impractical to test all the individual process elements for performance. In general, all the critical task elements are selected for creating the load rather than a complete business process.

In the workflow scenario, instead of taking a business process-based scripting approach, encompassing the entire business process, we need to take a task-based approach, which covers only the selected tasks of a business process. Tasks are otherwise called “Work items” in workflow terminology. Here, the scripting is done for each work-item according to the user role eligible to do that job as shown below. Each role logs in and repeats their assigned tasks and logs out at the end of the day.

In this approach if we run each script with different virtual users count, then it would simulate a real work environment like many roles doing different jobs. This will help us to create load to test the performance.

Execution challenges

While executing the load test, typically, all the virtual users need to see their work-related pages at the time of login. There should be a required amount of data in the application database to simulate the real-time environment. Additionally, the database needs to contain the real-time data to reflect the information on the task for all the virtual users while running the load test.

We can take different approaches to this, such as loading the database by scripts or running the load testing scripts multiple iteration for each task sequentially. Other challenges could be taking back-ups of the database after every load test cycle. This can be done with the required support from the database team.

Further minor challenges exist including environment set up, test data preparation, user profile creation and correlation, among others.

Conclusion

Workflow based business processes need a different approach, for conducting performance testing, in a single user business process scenario. Though the performance testing tool and the procedure is the same for conventional business processes and workflow based business processes, there are other differentiating factors including approach, design and execution methodologies.

In terms of design, data requirement and database loading activities, the workflow based model is more challenging than conventional business processes. A critical analysis of requirements, strategy and execution process is required for workflow based testing, much more so than single user business process performance testing.

(Author is Sr. Manager, QA, Virtusa Corporation)