Review Checklist For Performance Testing

Review Checklist

This checklist has been created to assist you in the requirements review process. It is divided in the several categories that all have an effect on performance. The list can be extended as needed, but it contains all the essential questions. The checklist also indicates the document(s) where the answer on the question should be found.

A requirement is only correct if it is unambiguous. If for instance a requirement defines a certain response time, it must be clear under which conditions this response time should occur.

Question	Why do we ask this?
User Base
Total amount of users?	Defines the size of the user information database. (logins that need to be created for the simulation)
How many concurrent users?	Defines the load that the system should be able to handle. Concurrent means: How many users are busy with the system,
How many peak users?	Defines the maximum load that the system should be able to handle.
How often are the peaks and when are they occurring?	Defines how often the maximum amount of users occurs and when the peaks are occurring.
Roles of the users?	Defines the break down of the users in roles that could have different impact on the system resources. For instance: ESR, data entry, management, supervisor etc.
Which roles support which business functions/ user scenarios?	Defines the break down of the users in roles/ activities that could have a different impact on the system resources
Location of the users?	Defines potential remote connections and therefore specific test requirements.
Network connection methods of the users?	Defines if the users need to connect through alternative mechanisms (instead of the LAN). This could result in specific test requirements.
Activities
Supported business functions?	Defines the different unique business functions and enables the test group to assess the resource usage per business function
Business functions ranked by frequency	Defines how often certain business functions are used in order to assess the overall resource usage.
User scenarios	Defines how the system will be used by the users. It is necessary to simulate this in a performance test.
User scenarios ranked by frequency	Defines how often certain scenarios are executed so that you are able to define a correct simulation. This will result in information about the throughput of the system
Batch run times	Defines how much time is set aside for batch programs to run and therefore how much time in a day is available for the online system. This is needed to estimate the daily throughput.
User scenarios ranked by response sensitivity (talking on the phone with a client)	Defines the scenarios that belong to front office and to back office. In the simulation, special attention can be given to the front office activities.
Environmental Constraints
Operating hours?	Defines the requirements related to stability of the application. If the application is supposed to be 24/24, then tests related to this requirement should be executes to assess the stability of the system components.
Dependencies on other systems?	Defines how other systems could potentially influence the performance results of the system under test. If a significant influence is expected then this influence should be simulated in the tests.
Dependencies on system resources?	Defines how specific system resources could potentially influence the performance results of the system under test. If a significant influence is expected then this influence should be simulated in the tests
System resources are shared with?	Defines how specific shared system resources could potentially influence the performance results of the system under test. If a significant influence is expected then this influence should be simulated in the tests.
Security requirements that might impact performance (SSL, firewalls, SSO)	Defines how specific security requirements could potentially influence the performance results of the system under test. If a significant influence is expected then this influence should be quantified in the tests.
Response times
Information request	Defines the general performance expectation for this activity. Information request is the retrieval on information based on a user-supplied key.
Value lookup	Defines the general performance expectation for this activity. Value lookup is the retrieval of a code value description.
Save/Submit entered information	Defines the general performance expectation for this activity. Save/ Submit is storing the new or changed information in the database.
Search information	Defines the general performance expectation for this activity. Start to print is defined as the time between giving the print command to the time that the printer starts to print
Start to print	Defines the general performance expectation for this activity. Start to print is defined as the time between giving the print command to the time that the printer starts to print
Time to print	Defines the general performance expectation for this activity. Time to print is the time that it takes for the print action to be finished measured from the time that the printer starts.
Window/ Page appearance	Window/ Page appearance refers to the time that it takes for a new window/ page to show up and be able to be used.
Window/ Page operational	Window/ Page operational refers to the time that it takes to operate features in the window like pushbuttons, list boxes etc.
Front office/ Back office values for all of the above	Defines the difference between the expected response times of a front office function and a back office function
Risks
What are the risks to the scenarios, the system, the Company if performance criteria are not met?	Defines the risk that will drive the plan for Performance Testing.
Common risks factors: ·         Large user base ·         New technology ·         Unproven technology ·         New use of existing technology ·         Inexperienced team ·         High peak usage ·         Large portion of front office activities	These are the most common risk factors related to performance.