What is Performance Testing Risk Assessment?
The life cycle of Performance Testing starts with Risk Assessment. Risk Assessment determines the neediness of performance testing for each individual component in a software system. Hence Risk score or matrix is calculated for all the components integrated into a system. This risk score helps to determine the criticality of the component from the performance testing perspective.
Purpose of Risk Assessment:
Risk assessment is conducted to decide the scope of performance testing in a project. Risk assessment helps to understand the impact of changes on the existing functionality. Also, the impact of adding new functionality to the existing system. It also helps to identify the in-scope and out of scope components for performance testing.
Performance Test Manager or Lead who has the component level understanding of the software system can conduct the risk assessment from performance testing perspective.
Performance Test Manager or Lead; either of them has to schedule a meeting with the project team. In the call, he should aim:
- To get the detailed information of new functionality
- Impact of changes on existing functionality
- Discuss the change in the load/volume
- Discuss and agree on the impacted components which require performance testing.
Likewise, the Performance Test Manager/Lead decides the scope of performance testing. If an end to end performance testing is not in-scope then some of the components can be de-scoped from performance testing on the basis of a risk score. In the risk assessment, there are certain parameters which help to decide whether a particular component needs performance testing or not.
At the end of this phase, Performance Test Manager/Lead prepares Risk Assessment Document comprises of performance testing scope. All the project stakeholders should sign-off this document before the closure of the Risk Assessment Phase.
How to proceed practically?
In 80% of cases, the application is new for a Performance Test Manager/Lead. If this is the case then he should follow the below steps to conduct a fruitful risk assessment:
Understand the application architecture: If the application is totally new for a Performance Test Manager/Lead then he needs to set-up multiple calls and meetings with the project stakeholders like business associate, application architect, developer, QA team etc. to understand the application. It is advisable to collect all the information about the system and its architecture and make some handy notes.
Refer Project Document: The software development documents like HLD (high-level design document), LLD (low-level design document), AO (Architecture Overview document) etc. help a lot to understand the design of the application.
Set-up Meetings/Calls: In the absence of these documents one-to-one meetings (calls) or combine meetings (calls) with all the stakeholders fulfil the purpose.
Risk Assessment document is started to draft when performance testing team is involved in the project. Ideally, the risk assessment should be conducted at the planning phase of the project, but practically there are so many challenges like the change in project scope during initial or development phase, change in strategy etc. which can make initial risk assessment worthless. Hence performance testing risk assessment is conducted either at the end of the development cycle or when functional testing starts. As stated earlier, one point to note here is risk assessment is the beginning of the performance testing phase, so all the activities related to performance testing should be started post risk assessment only.
Risk Assessment Document Template:
Download the template of the Performance Testing Risk Assessment Document.
PerfMate (Who is he?) got a project ticket to engage the performance testing team for a project named PerfProject (a virtual project of an e-commerce site) whose development cycle has been completed and functional testing is going to start. PerfMate accepts the ticket and kick-off the first phase of Performance Testing Life Cycle i.e. Risk Assessment.
In the first email to the project team, PerfMate requests for project documents like AO (Architecture Overview), HLD (High-Level Design) etc. Once he receives all the document then he starts studying them thoroughly. He finds out the majorly impacted functionalities and components due to the new changes and list-out the scope of the performance testing.
Then, he schedules a meeting with the project team in which he invites all the important project stakeholders like Project Manager, Project Architect, Business Analyst, Application Development Manager etc. and explains his understanding about the project and scope of performance testing. The call was fruitful and concluded with below points:
- The code level changes impacted the below components:
- Web Server
- Application Server
- Database A
- Database B
- The component out of scope
- Middleware A
- Reporting Server
- The identified business scenarios
- Buy a Product (End-user)
- Cancel an Order (End-user)
- Add a Product (Seller)
- Remove a Product (Seller)
- Approve a Seller Request (Admin)
- Approve a Product Request (Admin)
- Register a Complain (Customer Care)
- Out of scope business scenarios
- Update cart (End-user)
- Remove a Seller (Admin)
- Reject the Product Request (Seller)
- Refund the Amount (Seller)