Test plan – document that describes the entire scope of testing work, starting with a description of the test object, strategy, schedule, criteria of starting and ending testing, till necessary equipment, specialized knowledge and risks assessment with options for resolving them.

Test-plan is needed for:

  • setting up testing processes;
  • prioritization of tasks;
  • resource planning;
  • software and human resources accounting.

Normally, the test plan is compiled by the QA-lead of the tester team. But it can be edited repeatedly by the testers themselves.

A high-quality test plan should consist at least of the following items:

1. What needs to be tested?

In this paragraph, it is necessary to describe the test object in detail. This may be a description of the system, application and equipment. If the object of testing is an application, then list all its functional blocks. It is also necessary to indicate on which equipment and in which browsers the testing will be performed.

2. How will the testing be provided?

This paragraph requires a detailed description of the testing strategy. It is necessary to list all the types of testing and how they will be applied to the test object.

3. When will the testing be done?

At this stage is described the sequence of work:  Preparation, Testing, Result analysis in the context of the planned phases of development. It is very important here to indicate the dates or criteria for the transition from one phase to the next.

4. Criteria for the test start

Depending on the specific project, the criteria for starting the test may vary. Examples of some possible options are listed below:

  • readiness of the test platform (test bench);
  • completeness of the required functionality development;
  • availability of all necessary documentation.

5. Criteria for testing completion

  • the requirements for the number of open bugs are fulfilled;
  • holding a certain period without changing the source code of the Code Freeze (CF) application;
  • holding a certain period without opening new bugs Zero Bug Bounce (ZBB);
  • all tests passed successfully;
  • all bugs with high and medium criticality are closed.

If during the preparation of the test plan you answer all these questions, you will get a good draft version of the test planning document. After that, it needs to be finalized, based on the points indicated below, and the test plan will be almost ready:

  • environment of the tested system (description of hardware and software);
  • equipment and software, which is necessary for testing (test bench and its configuration, programs for automated testing, etc.);
  • risks and ways to resolve them.

Depending on the concretization of the described tasks, test plans are divided into certain types:

  1. Master plan or Master test plan– includes High Level information, which during the testing process does not often change and the requirements for which are not often reviewed.
  2. Test plan or a detailed test plan is a flexible document. Changes are sometimes made to it, which reflect the real condition of the project. It also contains more specific information about the strategy, types of testing, work schedule, etc.
  3. Product acceptance plan is a document that describes a set of activities related to acceptance testing (strategy, date, responsible employees, etc.).

The main difference of the master test plan is that it is more static. Typically, a project uses one master test plan and several detailed test plans that describe the individual modules of a single application.

To increase the value of the test plan, project team members must review and approve it from time to time. This is done either by agreement within the team or by the “approval procedure”.

A list of project team members who are authorized to approve the test plan:

  • lead tester;
  • test manager (quality manager);
  • development manager;
  • project manager.

All of the above project participants write a review, as well as submit their comments and suggestions, what will make the test plan more complete and high-quality.

The classic detailed test plan takes from few to several tens of pages. But at the same time, its general structure is always same. Typically, a test plan has the following structure:

1st page:

  • header (company logo and address);
  • name of the test plan;
  • version of the test plan;

2nd page:

  • history of the document with a table of changes. This table contains next columns: date, version, description, author.

3rd page:

  • contents of the test plan.

4th and next pages:

  • introduction;
  • types of testing;
  • operating systems, browsers;
  • application functionality;
  • criteria for testing start;
  • criteria for testing exit;
  • equipment specifications.

Penultimate page:

how many working hours are planned at various stages (start and end dates), for example:

  • for test design;
  • to perform tests;
  • for test analysis;
  • for reports.

Last page:

  • conclusions and recommendations.

Team of testers, contact details, bug life cycle, testing risks, links to documents or standards, explanatory dictionary, schedule, responsibilities – all of this can be also included in the test plan. Separate attention should be paid to risks as they can be related to staff disadvantages. For example, insufficient staff qualifications or insufficient number of testers.

The test plan is an important element in the qualitative organization of the testing process, as it includes all the necessary and important information that describes testing process. Creating a test plan improves the quality of the product by listing the details and a list of checks, and also allows you to analyze how successfully all stages of testing have been conducted.