What is Performance Test Planning?
A method called performance test planning establishes a plan for carrying out successful performance testing. One of the crucial stages in the performance test life cycle is this one, during which a performance tester develops a strategy for testing a program or system. Such a strategy is founded on the findings of the phases of gathering non-functional requirements and risk assessment. A document called the Performance Test Plan contains the final strategy and all the supporting data.
Purpose of Performance Test Plan:
Performance testing may be carried out easily and advantages can be obtained to meet project deadlines when tests are executed according to a well-planned plan with all the relevant data and coordinated assistance. Therefore, it is a good idea to create a thorough performance test plan that includes data about the support team alignment, realistic test goals, an accurate test approach, expected results, known risks, and detected difficulties and issues.
Accountability:
With the aid of the information he has gathered throughout the Risk Assessment and NFR Gathering phase, the Performance Test Manager or Performance Test Lead is responsible for creating a workable performance test strategy. The performance test manager or lead’s other duty is to explain the test strategy to the team members and give them complete information on the performance testing scope, script protocol, execution cycle, etc.
Approach:
In this phase, Performance Test Manager/Lead jots down the following details in the performance test plan document:
- Describe the non-functional requirement and scope
- Map the non-functional requirements with non-functional tests
- Develop the strategy for test execution
- Define the entry and exit criteria of the test
- Decide the number of execution cycles as per project timelines
- Collect the information about environment scaling
- Test data creation/preparation plan
- Highlight RAID (Risk, Assumption, Issue, and Dependency)
- Performance Testing Timelines
A portion of the data is readily accessible from the earlier periods. more meetings, calls, or email exchanges may be necessary to discuss more information, such as environment specifics, test results, etc. If the performance test environment is shrunk, NFR must be updated in accordance with the size of the environment’s %, and a provision for extrapolating the findings must be made. The risks and presumptions related to extrapolation and scale-down testing must also be carefully recorded.
Indicating reliance and the point of contact (dependency owner) is another crucial issue. Example: Before the performance test’s start date, the test environment should be prepared (Owner: ABC). As soon as the performance test strategy is complete, present it to the project team and obtain key stakeholder approval. The Performance Test Manager or Lead should communicate the approved performance test plan to the team members so they can comprehend the testing strategy and create the test script and scenario in accordance with the method outlined in the plan.
Deliverable:
The primary output of this phase is the Performance Test Plan, which includes a thorough performance testing strategy for carrying out test execution and identifying performance bottlenecks.
Tests with defined NFRs:
| NFT=> NFR ID | Load Test | Stress Test | Soak Test | Spike Test |
| NFR01 | √ | |||
| NFR02 | √ | |||
| NFR03 | √ | |||
| NFR04 | √ | |||
| NFR05 | √ | √ | √ | √ |
| NFR06 | √ | √ | √ | √ |
| NFR07 | √ | √ | √ | √ |
| NFR08 | √ | √ | √ | √ |
| NFR09 | √ | √ | √ | |
| NFR10 | √ | √ | √ | |
| NFR11 | √ | √ | √ | |
| NFR12 | √ | √ | √ | |
| NFR13 | √ | √ | √ | |
| NFR14 | √ |
Following are the scripts which need to be created during the test design phase:
| Role | Script ID | Script Name | Purpose | Additional Details |
| Admin | Script01 | adm_seller_request | To approve/reject a new seller request | The script should have both approve and reject request scenarios. 80% of total requests will be approved and 20% will be rejected. |
| Admin | Script02 | adm_product_request | To approve/reject a new product request | The script should have both approve and reject request scenarios. 90% of total requests will be approved and 10% will be rejected. |
| Seller | Script03 | slr_add_product | To add a new product | |
| Seller | Script04 | slr_delete_product | To delete the existing product | 10% of seller transactions |
| Buyer | Script05 | byr_buy_product | To buy a product | |
| Buyer | Script06 | byr_cancel_order | To cancel the ordered product | 4% of buyers cancel the product |
| Call Center | Script07 | cce_register_complain | To register buyer/seller complain |
As was already said, a typical performance test plan includes all the essential details needed for test execution. A performance test plan is really an agreement between a client and a performance testing team that is used to validate whether or not the findings meet the customer’s expectations at the time of the test report. The information included in the test plan is used to inform the conclusion of the performance test report.
The RAID (Risk, Assumption, Issue, and Dependency) is likewise included in PerfMate, along with the owner and impact of each RAID. RAIDs are crucial sections of the test plan that protect the performance testing team during crucial times, such as when the project begins harassing and blaming performance testing in the event of any execution delays; provided, however, that RAIDs are clearly written and the correct owner, date, and his/her signature are provided along with them.
The performance test plan is finished by PerfMate and shared with the project team for approval. He has a meeting with his team in the meantime to discuss the performance testing strategy for this project (PerfProject). The necessary testing and monitoring tools, testing scenarios, and schedules are also covered by him. After receiving a new project, his team is eager to learn new things.
