Service Level Agreements (SLA)

For performing the Functional Testing, we used to have the Functional Specification Document where all the functional requirements are defined. The Functional Specification Document describes; how the system is going to behave and work. It helps the Testers to outline what tests to run and designing/retrieving the test plan & test cases out of it. 

The Performance Testing falls under the Non-Functional Testing. You must be wondering is there any Specification Document also available for the performing the Performance Testing. Well, it depends. Sometimes it might available and sometimes not. Okay! the formal name of the Performance Testing is said to be "Service Level Agreements (SLA)". The SLA is a generic term which is an agreement between two or more parties, where one is the Customer and the others are the Service Providers. Here, we're discussing the SLA related to Performance Testing. The performance objectives are often specified in a service level agreement (SLA). This document is used for gathering the requirements before the Performance Testing begins. 

Basically there are two type of Service Level Agreements (SLA). One is System Availability which ensures the application is up by some predefined duration which is generally not feasible to test out. The typical example for the System Availability will be "The application needs to be available 24 hours per day except on Weekends". The other type is Response Time which is duration of specific module or page of the application. The example for this SLA would be; "An user needs be logged on into the application by 3 seconds". 

The following are some examples of SLA for the Performance Testing of various parameters.

• User base Supported (For Example: 5000 Users)
• Expected Response Time: (For Example: 5 sec.)
• Expected CPU Utilization: (For Example: Less than 70%)
• Expected Memory Utilization: (For Example: Less than 70%)

The Service Level Agreements (SLA) needs to be well documented and shared among all stake holders of the Project including Business Manager, Developers, Testers, and Marketing Professionals. The Service Level Agreements (SLA) is the document on which the Software Testing Life Cycle gets initiated for the Performance Testing.

An introduction to Performance Testing!

Performance is the quality of performing certain task. The quality might be excellent, moderate, or poor depending on the combination of Systems, Components, Environments, Manpower, or any other depending factor. Performance Testing helps to evaluate the anticipated load and concurrency which would be expected to encounter in the real world.

When an application is being build on, it passes through a number of testing phases. Starting from Unit Testing to System Testing but is it enough to be done prior release to the end users? No, it's not sufficient enough. It also depends on what type of application it is and who are it's audience. If it's a light weight website of a Company, probably we do not to perform Performance Testing because the target audience will be very less. But if it's an application which targets every age group, such as; social medias, video portal, etc. then it becomes essential to do the Performance, Load, and Stress Testing.

Okay, now let's discuss about the terminologies used on Performance Testing.

1. Capacity
The capacity of a system is the total workload it can handle without violating predetermined key performance acceptance criteria.

2. Resource Utilization
Resource Utilization is the cost of the project in terms of system resources. The primary resources are processor, memory, disk I/O, and network I/O.

3. Latency
Latency is a measure of responsiveness that represents the time it takes to complete the execution of a request.

4. Response time
Response time is a measure of how responsive an application or subsystem is to a client request.

5. Saturation
Saturation refers to the point at which a resource has reached full utilization.

6. Scalability
Scalability refers to an application’s ability to handle additional workload, without adversely affecting performance, by adding resources such as processor, memory, and storage capacity.

7. Stability
In the context of performance testing, stability refers to the overall reliability, robustness, functional and data integrity, availability, and/or consistency of responsiveness for your system under a variety conditions.

8. Throughput
Throughput is the number of units of work that can be handled per unit of time; for instance, requests per second, calls per day, hits per second, reports per year, etc.

9. Utilization
In the context of performance testing, utilization is the percentage of time that a resource is busy servicing user requests. The remaining percentage of time is considered idle time.

10. Workload
Workload is the stimulus applied to a system, application, or component to simulate a usage pattern, in regard to concurrency and/or data inputs. The workload includes the total number of users, concurrent active users, data volumes, and transaction volumes, along with the transaction mix.

11. Metrics
Metrics are measurements obtained by running performance tests as expressed on a commonly understood scale.