Process for Identification of Key Business Scenarios for Performance Testing

1.      Introduction

2.      Criteria

2.1.       Contractually Obligated Business Scenarios

2.2.       Frequently Used Scenarios

2.3.       Business Critical Business Scenarios

2.4.       Performance Intensive Business Scenarios

2.5.       Technologies Concerning Business Scenarios

2.6.       Stakeholders Concerning Business Scenarios

2.7.       Time Dependent Frequently Used Scenarios

3.      Approach

3.1.       Identification of All Scenarios

3.2.       Identification of All Activities of a Scenario

3.3.       Scenarios vs. Identification Criteria

3.4.       Listing of Key Business Scenarios

3.5.       Sharing of Key Business Scenarios to All Stakeholders

3.6.       Finalize

4.      Conclusion

1.    Introduction

Identification of key business scenarios is one of the important activities during the performance testing.  The activity takes place during the “Discover” phase.

It plays a vital role as the performance testing needs to simulate the actual scenario, for giving the best results, when the performance problems occur in the production.

2.    Criteria

Following criterion can be used while identifying key business scenarios for an application.  Human users as well as system users (batch process, external application etc.) should be considered while identifying the key business scenarios.

2.1.      Contractually Obligated Business Scenarios

These are scenarios / features that exist because of contract.  These scenarios might not be frequently used scenarios but can cost the company dearly in case of any breakage of scenarios during stress point. For example, it might be mandatory for brokerage web application to list all digital contracts at one place, which can be viewed by customers at any time.  The viewing of contracts details might not be a frequently used scenario.

Contractually obligated Business scenarios can be found by -

• Reading contracts
• Reading requirements & use cases
• Reading marketing material
• Interviewing stakeholders

2.2.      Frequently Used Scenarios

These are the most commonly used scenarios in an application.  For example in any of the e-commerce application, browsing for products, placing an order can be the most common / frequently used scenarios.

Frequently used scenarios can be found by -

• Analyzing web log files (existing application)
• Reading information from similar existing product(s)
• Observing and asking questions to beta testers / prototype users

2.3.      Business Critical Business Scenarios

These are scenarios that might not be frequently used but are very important for the business. For example, doing opinion polls while user is browsing the web application.  In case opinion polls starts failing at stress / failure point?  The business might lose important details from customers.

Business critical scenarios can be found by -

• Reading marketing material
• Interviewing stakeholders

2.4.      Performance Intensive Business Scenarios

These are scenarios that are resource intensive.  The reason these scenarios should be added in workload to make sure nothing wrong happens when these scenarios are running.  These scenarios might lock a large table which might start returning timeout errors for other requests. For example, viewing of last one year bank statement.  These might not be most commonly used scenarios.   The primary resources are Processor, CPU, Memory and Disk.

Performance intensive Business scenarios can be found by -

• Reading design documents
• Asking developers

2.5.      Technologies Concerning Business Scenarios

These are scenarios that might not be frequently used but technology stacks being for the scenarios be different from other scenarios.  For example, uploading of file(s) using FTP.

Technologies concerning Business scenarios can be found by -

• Reading design documents
• Asking developers

2.6.      Stakeholders Concerning Business Scenarios

These are scenarios that are highly visible (pet features of stakeholders.) It might be newly added features.

Stakeholders concerning Business scenarios can be found by -

• Interviewing stakeholders

2.7.      Time Dependent Frequently Used Scenarios

These are scenarios that are used frequently for certain period of time.  For example, in online payroll application viewing of pay slips requests increase during month start.

Time dependent frequently used scenarios can be found by -

• Analyzing web log files (existing application)
• Reading requirements and use cases

3.    Approach

To identify key Business scenarios of an application, the following approach can be used.

3.1.       Identification of All Scenarios

List down all scenarios / transactions (frequent or infrequent) being used in an application.  Examples of few scenarios from social networking site are -

• Adding friends.
• Sending message to friends.
• Sharing photos

3.2.      Identification of All Activities of a Scenario

List down all activities associated with a scenario.  It becomes important in identifying one of the key Business scenarios if one of the activities is resource intensive.  For example, if activities involved for “Adding friends” scenario are -

1. Login to application
2. Search for a friend
3. Select the name from the list
4. Verify selected name is his / her own friend
5. Add friend

In above scenario, after listing the activities it becomes clear that it is performance intensive operation. 

3.3.      Scenarios vs. Identification Criteria

Iterate thorough all scenarios and validate it against identification criterion.

Below every transaction is rated against every parameter (Contractually obliged, frequently used, business critical etc.) on a scale of 1 to 5 (1 being lowest and 5 being highest importance.) Weightage for each parameter is based on the importance of the parameter.   The weightage is given on scale of 1 to 3 (1 being lowest and 3 being highest importance.)  The score of parameter of every transaction is calculated by multiplying the transaction rating with parameter weightage and later transaction score is calculated by adding all parameters’ scores.

For example, score of transaction ‘Add Friend’ is calculated as below –

Add Friend (Score) - 1*3 + 4*2 + 4*3 + 1*1 + 1*1 + 5*2 + 1*2 = 37

Transaction	System / Human User	Contractually Obliged	Frequently Used	Business Critical	Performance Intensive	Technically Concerning	Stakeholder Interest	Time Dependent Frequently Used	Score
Weightage		3	2	3	1	1	2	2
Adding Friends	User	1	4	4	1	1	5	1	37
Sending Message	User	5	5	5	1	1	5	1	73
Sharing Photos	User	3	4	4	4	2	5	1	87
Help About	User	5	2	1	1	1	1	1	39
Data Cleanup	System	4	1	5	5	3	1	5	41

3.4.      Listing of Key Business Scenarios

List down all key Business scenarios by analyzing the table created in section 3.3. (Scenarios Vs. Identification Criteria).   From above table, it can be seen that all transactions except “Help About” are key Business scenarios.

So, key Business scenarios would be -

1. Adding Friends
2. Sending Message
3. Sharing Photos
4. Data Cleanup

3.5.      Sharing of Key Business Scenarios to All Stakeholders

Once the key Business scenarios are analyzed and documented.  The document should be shared to all stakeholders.  They can review the same and add / delete the key scenarios with their reasoning i.e. why they think a scenario is key scenario or not a key scenario.

3.6.      Finalize

Once the lists of key scenarios are reviewed and comments are incorporated.  The key Business scenarios list should be signed – off and finalized.

4.    Conclusion

Once key business scenarios are identified, it can be used as an input for developing a valid performance test plan.

Courtesy: http://rgsoftwaretesting.blogspot.com.au/2012/02/process-for-identification-of-key.html