An "Ideal" Interview with the Tester for Performance Engineering Position Part 2

For part 1, click here

Interviewer: What do you do when you are asked to start performance testing on a web application. 

Candidate: First of all, I try to understand the application, its main functionalities, its architecture and technologies used.

Of course, this information will be given by developers. We will also need developers to help in the later stages of performance testing. 

After that, I normally follow 5 steps to do performance testing. 

The first step is to identify the performance test environment. 

The good rule of thumb is that our test environment should be exactly similar to the production environment. But in many organizations, this could not be the situation due to cost. So we try to create an environment which is as close to production as possible. The Test environment could be a Virtual machine in which we can increase or decrease the RAM and processing power when needed.

Some critical factors to consider are:
Network Limitations, Hardware Configurations, Load Generation Tool, Logging mechanism, Licensing constraints etc. We do need the help of Network/IT team in designing the test environment. 

The second and most important step is to identify the performance acceptance criteria. This will be provided by business analysts, product owners who understand the business side of the application. If acceptance criteria are not clearly defined, the whole performance testing activity will become haphazard and inconclusive. 

Interviewer: So can you give some examples of some performance acceptance criteria?

Candidate: Performance criteria are highly subject to the context of the web application. But I can give some examples. Normally performance characteristics include 

Response Time:
For example, Response times for all business operations during normal and peak load should not exceed 6 seconds.

Throughput: 
For example, the system must support 25 book orders per second. 

Resource utilization: 
For example, No server should have sustained processor utilization above 80 percent under any anticipated load or No single requested report is permitted to lock more than 20 MB of RAM and 15-percent processor utilization on the Data Cube Server.

There could be any number of performance acceptance criteria, but they should all be quantifiable and correlate to user satisfaction. 

Interviewer: Good. You mention throughput, can you define what is it?

Candidate: It is the unit number of work server can handle per time unit. You can measure throughput in terms of
requests per second or
reports per year or
hits per second or
calls per day or any other number per unit time.
The higher the throughput, the higher the performance of the server is.

Interviewer: Great. So what if we don't have any idea for user expectation. What strategy should we use?

Candidate: You can just ask the user that what performance you are expecting?

Interviewer: (Laughing...) no no. I meant to say that suppose we are building a product and until now we don't have any user for that product because we have not launched that product. So how would we define the performance criteria for that?

Candidate: In that case you should follow benchmarking or baselining.

Interviewer: What is benchmarking and baselining?

Candidate: Benchmark tests are the process of comparing the performance of your system against industry standards given by other organizations. One example of benchmarking is that you can see how your competitor's application performance is. Another example is that you can read the research papers from top performance engineers and see what they propose for ideal benchmarks for your domain.

Baseline, on the other hand, is a comparison with your previous releases. You can set one particular release as your baseline. All future releases performances will be compared to that baseline. If results of any release are much degraded from the baseline that means something is wrong with the performance. if any release is performing better, you can change your baseline and set this release as your baseline. 

Interviewer: Good Answer. So what is the next step after identifying performance acceptance criteria?

Candidate: Next step is to design tests. When designing tests, we should identify key usage scenarios, determining appropriate variability across users, identifying and generating test data and specifying the metrics to be collected.  

When designing tests, our goal should be to create real-world simulations in order to get results which help stakeholders to make informed business decisions. We should consider 

Most common usage scenarios, 

Business-critical usage scenarios, 

Performance intensive business scenarios 

And High visibility usage scenarios.

It is useful to identify the metrics related to the performance acceptance criteria during test design so that the method of collecting those metrics can be integrated into the tests when implementing the test design

Interviewer: What other considerations you should follow while designing tests?

Candidate: When we design realistic test scenarios, we should incorporate realistic simulations of user delays and think times which are crucial to the accuracy of the test. Secondly, we should not allow the tool capabilities to influence our test design decisions. Better tests almost always result from designing tests on the assumption that they can be executed. After that, we should see that what tool can do. Thirdly we should involve the developers and network administrators in the process of determining which metrics are likely to add value and which method best integrates the capturing of those metrics into the test. For example, if we want to know the CPU utilization, we should take help from network administrators that how we would capture CPU utilization in our test. 

Interviewer: Good. So up till now, we have discussed 3 steps while starting performance testing. Up till 3rd step, what do you feel some biggest challenges are?

Candidate: I think the biggest challenge is to correctly identify the performance acceptance criteria. I cannot force enough is to how important this step is and how important is that for every stakeholder to involve in this step. Developers, Testers, Product Managers, Network Engineer and Performance Engineers they all should be part of this decision. 

The second biggest challenge is getting our first relatively realistic test implemented with users generally being simulated in such a way that the application under test cannot legitimately tell the difference between the simulated users and real users. This takes significantly longer time and again input from all stakeholders is very necessary for this step. 

Interviewer: Right. I agree. So what is the next step?

Candidate: Next 2 steps are remaining. Execution of the tests and Analysis of results. 

To be continued.....