The Basic Concepts Of Performance Test - Time Behavior

I- What is Time Behavior?

Time behavior is the measurement of an application's ability to react to different events over time, encompassing the duration required for the application to perform particular actions such as loading a page, running a query, or processing a transaction. Time behavior also includes evaluating how the application performs under various loads, including high traffic or heavy user activity.

II- Why Is Time Behavior Important In Performance?

• Time behavior is a critical aspect of performance testing as it helps in identifying potential bottlenecks and performance issues. By measuring the application's response time under different scenarios, performance engineers can identify which parts of the application are causing delays and where improvements are needed. This information can help developers optimize the application's performance and improve its overall efficiency.
• Time behavior also plays a crucial role in user satisfaction. Users expect applications to respond quickly and efficiently, and slow response times can result in frustration and dissatisfaction. By understanding the application's time behavior, developers can ensure that the application meets users' expectations and provides a seamless experience.

III- Measuring Time Behavior In Performance Testing

Time Behavior in ISO 9126 quality management:

Time Behavior in ISO 25010 quality management:

The time behavior evaluation is the most common objective of the performance testing. This aspect evaluates the ability of a component or system to respond to user behaviors within a specified duration and under the other conditions. The time behavior measurements can differ between the system's response time from user input and the number of CPU cycles needed by a software component to perform a specific task. Since time behavior is a quality metric for dedicating the system to good or bad performance, it becomes the necessary metric to be verified while doing performance verification.  Many questions can be raised while gathering the performance requirements. A defined goal's first priority is the user behaviors' response time as

• If the actual response time is exactly 2 seconds, is it a failure expectation?
• What about 2.01 seconds?

Time behavior can be measured differently. It should become the standard practice  for the performance engineer to acquire the performance requirements from the stakeholders. The performance engineer can ask the following questing for the TIME MEASUREMENT:

• Is this the maximum response time? 
• Is this the average response time?
• Is this a percentile time and if so, what is the exact percentile?

Increasingly, the percentile measure is being used. It can be more useful to know that 95% of the user responded within two seconds than dining a maximum response time. And the other concerned questions are:

• Why should it be 02 seconds? Should it be less than?
• What are the impacts if the system under test took longer than the expected response time?
• Would the business lose the customers if the application makes them wait longer than the expected response time?
• How does the longer wait time affect the user’s experiences?
• What does “response time” mean?
• Does the response time mean that the time of transaction has completed the entire operation? Or that a connection time to the target server has been completed?
• What’s the system?
• Is the time of transaction measured from the end user’s local machine through the application stack and back to their local machine? 
• Or is response time measured from the point the web request passes the organization firewall through the application stack and back to the firewall?

Crucially, for what user actions or behavior is the attainment of a two-second response time deemed necessary? Is a single user logging in, and logging out of the system? Five users? A thousand? And thousands? What happens to the system's performance? How does the system scale up to satisfy the client’s behaviors? 

Besides, the total number of transactions that need to be completed (throughput) can also affect the timing behavior. A single transaction being processed can complete quite quickly, while a thousand transactions being processed together (much higher throughput rates) can take longer.

IV- Time Behavior In Static Testing

The performance engineers can detect and remove defects early in the software development lifecycle before the code execution by reviewing the requirements, architecture designs, and implementing source code. This activity is called Static Testing.

So, in the static testing the performance issues can be found beyond the scope of the project. Ultimately, static testing can also allow the performance engineers to ask relevant questions against the non-executable components of the project for detecting the potential issues of time behavior as below:

• Will the response time be within the defined time constraints?
• Have all the all time constraints been explicitly defined in relation to average, maximum, or percentile response times?
• Have all temporal restrictions been precisely delineated with regards to response times in terms of mean, maximum, or percentile values?
• Have these response times been validated against real-world scenarios?
• Has the assessment of these response times been carried out by various parties involved in the project? 
• Has the evaluation of aggressive time behaviors' effects, such as extremely low response times, been conducted in relation to the other project features, including cost, scope, quality, and risk?

V- Conclusion

Time behavior is a fundamental concept in performance testing that helps in identifying performance issues and optimizing application performance. By measuring response time, latency, and throughput, performance engineers can gain insight into the application's behavior under various scenarios and identify areas for improvement. Understanding time behavior is crucial for ensuring that applications meet users' expectations and provide a seamless experience.

References

• ISTQB Certified Tester Foundation Level Specialist.
• ISO 9126 quality management
• ISO 25010 quality management