Improve your contact center performance. See how you can make a difference.
Watch Now
Engage and build your ICT audience with CIOL online advertising.
Know more
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.
<< PREVIOUS NEXT>>
