Performance Test Plan: Why is it Needed and How to Write | DeviQA
LogoDeviQA is the finalist of the Software Testing Award 2019

Performance Test Plan: Why is it Needed and How to Write

By on 2021-02-04T00:00:00.000Z

Performance testing plays an important role in the QA process, giving an opportunity to establish high speed, scalability, and robustness of the software products. However, performance testing requires thorough preparation in order to provide accurate and useful results. In these terms, QA engineers must pay particular attention to a performance test plan that we are going to consider in detail in this article.

Why Performance Test Plan is Needed

Before you proceed to a formal performance test cycle, you need a detailed test plan. Performance testing is rather complex as it involves different types of testing and requires different data, predetermined conditions, particular test environment, and others. All these and many other factors must be covered with your test plan in order not to miss any aspect and ensure accurate results.

So, let's have a look at the major items of a performance test plan

Project background

Before diving into the performance testing details, it is worth describing shortly the main objectives of the application that should undergo performance testing.

Performance testing objective

You should define here the main purpose of your performance testing activities.

Entry Criteria

Entry Criteria

Your plan should include a list of all activities that must be completed prior to the performance test execution. For example:

UAT server must be available.

The development process must be completed, and the code must be frozen.

The final code must be deployed on the UAT server.

AUT must not contain blocker, critical, and major functional defects.

Required hardware infrastructure should be available and adjusted.

The final version of the Performance Test Plan must be signed-off by all those involved in the process of performance testing preparation and execution.

Test data should be available and tested.

As a rule, this plan point also provides a list of team members responsible for each activity.

Test Environment

Test Environment

Performance testing has much stricter requirements to a testing environment than functional testing has. It's essential to set up a test environment that replicates the production environment as much as possible, especially when it comes to the capacity, codebase, and integrations with other environments and servers.

Your plan should contain requirements for your test environment to make sure that it is suitable for your application and testing goals.

It is advised to include information on the components of your test environment:

Server name;

Environment tier;

Server vendor model;

Hardware version;

Operating system;


CPU (number of cores);

Total space of a driver.

Besides, it makes sense to add in your plan the scaling factors between the production environment and test environment. To the scaling factors we can refer:

the hardware of the same vendor family;

the same hardware version;

the same number of CPUs;

the same OS (UNIX, Linux, or Windows);

type of configuration files (a match to the production environment or pulled from the production environment);

the same level of data in the database.

Test Data

Test Data

The app server may have a different response to an empty test database and a production database that contains tons of data. Of course, you cannot use real production data for testing. That is why it is important to prepare test data thoroughly. For this reason, your plan should provide information on the test data required to execute performance test scripts. For Instance, you may need dynamic login data and variable data to avoid static iterations.

Your plan should also cover aspects related to required test data preparation, creation, and management:

The necessity to test the data and/or database to ensure readiness for the current test stage and correspondence with test requirements.

A list of tools that are needed to create, change, and manage the test data.

A strategy that will be used to receive and refresh test data for every performance testing cycle.

Requirements for the test data volume and other characteristics.


The scope of testing is an essential part of a performance test plan. It is defined on the ground of requirements that the app should meet, available resources, and business priorities. As a rule, the scope includes the information on particular features and main transactions that must be tested, types of tests, e.g., component test or end-to-end test, test scenarios, e.g., peak load test, disaster recovery, and others.

Of course, the scope of the performance test can be changed during the plan execution due to some unexpected conditions or new requirements and priorities. Still, it is useful to identify the scope from the outset and continually update it if needed.

Acceptance Criteria

It doesn't make sense to get to the performance testing if acceptance criteria have not been identified.

The acceptance criteria of the performance test should include the expected performance standards for the application under the testing, like acceptable transaction rate or response time per each component of the test scope. All in all, this plan item defines under which conditions tests are considered as passed and fail.

Test Approach

It is the main and largest section of the document. It describes in detail the process of performance testing, test scenarios, creation and validation of test script, as well as a testing location for each type of performance testing. Moreover, you should also indicate required testing tools, corresponding monitoring processes, and methods of bug handling and test result generation.

Test Schedule

Time management is of primary importance for performance test planning. It is needed to estimate the time required for the whole testing process and coordinate the work of each team member. For this reason, it is a good practice to include a schedule in your performance test plan where you identify the start date and end date of each testing activity.

Constraints and risks

All constraints and risks in regards to the software under the test, test environment, tools, dependencies, schedule, and other related items should be documented. It is recommended to define also impacts of possible risks and constraints.


Here you should provide a list of planned deliverables, i.e., metrics that should be checked and tracked, as well as assigned specialists responsible for their completing and delivering.


The prospect of performance test plan writing can seem to be daunting. Yes, this process requires a lot of time and effort, which will be justified at the end of the day. A comprehensive performance test plan can help you receive precise results and avoid possible risks and delays. Besides, as soon as you manage to draw up a template with which you pleased, you can use it over and over again for future projects, just with some modifications.