Performance Testing Life Cycle

The IT world is ever-changing and performance testing needs to provide quality assurance under demanding workloads that could change from one year to the next. The performance testing life cycle is all about ensuring that your software’s performance is able to operate at a high level even under less than ideal circumstances. In this blog, we will dive into a performance test plan, and it is important to understand that this document is only a portion of the complex life cycle of performance testing. The life cycle is the entire process from planning the test, through its execution and the steps for assessing and taking action on the defects that show up.

Performance Test Plan Sample

A performance test plan is a blueprint that outlines specific details for the scope and objectives of a project. The main purpose of this plan is to describe in detail the process that is going to be put in place to test new or changed components that aim to meet the predetermined performance requirements set by your team. The most important aspect of a test plan is that it ensures the actual test will reflect the real state of the project. There are a few key criteria that a performance test plan should include. 

• The specific testing activities that will be performed in the test, including the overall state of the test environment, test execution and analysis, and reporting
• The method of approach for the test, including the target volumes that are trying to be reached, and the number of users and data that will be used for the test
• Details about the constraints of the test, including a specific environment that will be required for a successful test, and specific tools that will be used
• Entry and exit criteria for the test

What are the 5 Most Important Components in a Test Plan?

Here are 5 vital components that need to be present in any well-put-together test plan.

• Project Scope: This section details the primary objectives of the test. It will also explain the scenarios that will be used within the test, and can also explain why certain scenarios or other parameters will not be tested.
• Deadlines: You should include at the bare minimum, the start date and end date. It would be helpful to also include dates for key metrics and when you are aiming to hit them by. The more detailed a schedule is, the easier it will be to stay on track to complete the objectives for the project.
• Testing Environment: This portion should detail the specific configuration and nature of the environment that will be used for the test.
• Risk & Defect Management: You need to detail both the actual bugs that are found and the method in which they will be reported and to whom they will be reported. The risks associated with your specific test should also be detailed in this section.
• Exit Plan: This section specifies when the testing will cease. You will also describe what results should be expected from a quality assurance (QA) standpoint.

How Do You Write a Performance Test Plan?

Writing a performance test plan is straightforward when you follow the IEEE 829 Standard for system and software documentation. This system has 18 attributes that must be included in the document. 

1. Test Plan Identifier: This is the title page for the entire test plan. Generate a unique identifier for the type of test (master test, level test, integration plan), as well as the date and version number for this test. Software documentation is dynamic and thus subject to change. These documents need to be kept up-to-date and version numbers will make this clear.
2. References: Here you will list all of the documents that you intend to use to support the test. It is important that you use the actual version of these documents, and that you do not duplicate them from any other source. A few examples of documents you can reference are:
   1. Developmental and testing process standards
   2. Specific methodology guidelines and examples of each
   3. Relevant corporate guidelines and standards
3. Plan Introduction: Indicate the purpose of the plan, and reiterate the level of the plan if necessary (e.g.., master). The introduction should also include a brief scope of the plan as it relates to the software project plan.
4. Test Items: These will be the items that you intend to test with this project. Either something you will test or a list of what is to be tested. If your team has a configuration management (CM) process, this portion can be controlled by it. 
5. Potential Software Risk Issues: You first need to identify what software is going to be used for the test, and more specifically, what are the critical areas, such as:
   1. A new version of the interfacing software
   2. Intense and complex functions
   3. Modifications to key components that have a noted history of failure
   4. Poorly documented changes to modules
6. Features to be Tested: Create a list of features that will be tested from the point of view of the user. This is less of a technical list and more of what the user makes of the functions. 
7. Features not to be Tested:  This will be from both the viewpoint of the user and a CM control view. You should identify not only what, but why the specific feature is not to be tested. These can be for any number of reasons including:
   1. The feature is not to be included in this version of the software
   2. The feature has a low-risk status and is thus considered stable
8. Approach/Strategy: Here you will outline your overall test strategy and should match the level of the plan. You should specify rules and processes:
   1. Are there special tools that need to be used, and what are they?
   2. What metrics will be tracked during testing?
   3. How will the CM be controlled?
   4. Will there be hardware and software specifications or notes
9. Criteria for an Item Pass/Fail: Make clear the completion criteria for the test. The criteria for a pass or fail result for the test should also match the level for the test.
10. Resumption and Suspension Criteria Requirements: It is crucial that you understand and note the requirements for a pause in testing. If the number of defects goes beyond a point where the testing loses its value, then testing should be stopped. 
11. Test Deliverables: This is where you lay out what will be delivered as a part of this plan. This can range from test documents, test design specifications, error logs, test cases, etc.
12. Remaining Test Tasks: There may be parts of the application that this plan does not address if the performance test life cycle is multi-phased. The areas that could be missed need to be identified so that users and testers can avoid complications
13. Environmental Needs: Here you need to identify any special environmental requirements for your testing. This could be any unique hardware that the test will require to function properly, as well as server bandwidth and even if certain systems will need to be taken offline during testing.
14. Staffing and Training Needs: Explain what kind of specialized training will need to be implemented on this system, and what type of tools will be used.
15. Responsibilities: Identify all areas of issues with the plan like setting risks, who provided the training, and who makes the critical decisions.
16. Schedule: The schedule that you create should be based on validated and realistic expectations. Inaccurate estimates of the project can throw off the results. 
17. Planning Risks and Contingencies: Identify what the risks to the project are with a focus on the testing process.
18. Approvals: Depending on the level of the plan, note who can approve processes and allow the project to continue to the next stage.

What are the Phases for Automated Performance Testing?

Automated performance testing checks the speed, response time, reliability, resource usage, and scalability of software that is put under an expected workload or a strenuous workload by leveraging automation. The typical steps in an automated performance test are as follows:

• Select your test tool
• Define the scope of your specific automation
• Plan, design, and develop your test
• Execute the test
• Automate maintenance 

Workload Model in Performance Testing

A workload model in the world of performance testing is identified as load distribution across all possible scenarios of the application under test (AUT). The workload model can accurately depict how the application will be used in an actual production environment like when the product is released to end-users.

Performance Testing vs Load Testing

Performance testing is an overarching term that encompasses both stress testing and load testing. Performance testing as a whole is about evaluating the overall performance of a specific system and collecting data on key metrics. Load testing is more akin to a technique of performance testing that works to verify if an application is able to handle an established expected load. Load testing is particularly useful for detecting bottleneck areas in a system.

Performance Testing Tools

While there are a variety of tools available for performance testing, we will keep our list to tools that Foulk Consulting uses for performance tests.

• Loadrunner
• NeoLoad
• Flood.io
• Octoperf

Trusted Work with Foulk Consulting

For more than 20 years, Foulk Consulting has provided high-caliber industry-leading services across the entire IT landscape. Whether working with a Fortune 100 company or a small, dynamic up-and-coming IT organization, Foulk Consulting will align your IT initiatives and transformation journey with our approach. Our ultimate goal is to improve your ability to serve your customers. If you would like to connect with us further, do not hesitate to contact us.