What Is a Test Plan?

A test plan is document outlining the goals, resources, and processes entailed in testing a software or hardware product. Why is this important? Prior to beginning a testing phase, it’s important to know which features will be tested, the specific tasks involved, which personnel will be involved at each step, and details about the testing environment.

Test plans are more commonly associated with automated, as opposed to manual testing, and can be broken down into various subtypes. Master test plans are higher-level plans that cover all other tests involved. There are then level-specific plans for unit testing, integration testing, system testing, and acceptance testing. You may find type-specific plans that focus on security or performance.

To formulate a complete test plan, you need:

An Introduction

Here you state the purpose of the test plan. This is where you would identify the plan level, i.e. master plan or level-specific.

List of Test Items

These are the items that appear within the scope of your test plan; this is what you’re testing.

Risk Issues

Identify the risks and complexities inherent in the product you are testing.

Features To Be Tested (User POV)

This entails a description of features to be tested from a user’s point of view (i.e. non-technical descriptions). This differs from the list of test items above.

Approach

This is your overall strategy for the test plan, which should match the level of the plan. It will include details such as special tools used for testing, the metrics to be assessed, and the forms of regression testing to be executed.

Pass/Fail Criteria

In other words, what is the completion criteria for the test plan. At a master level, are all subsequent level plans completed? At a smaller level, must all unit tests be completed? A specified percentage?

Suspension Criteria and Resumption Requirements

Set a criteria for when to pause a test if not operating properly or finding expected results.

Test Deliverables

Concrete deliverables include: test plan document, test cases, test design specifications, tools and their outputs, simulators, static and dynamic generators, error logs and execution logs, problem reports and corrective actions.

Remaining Test Tasks

If there are future portions of the software to be tested that do not fit within the scope of current testing, they may be worth sharing so as to prevent confusion (i.e. “this feature doesn’t seem complete”).

Environmental Needs

Is hardware required? What software (device/browser) specifications are required? How will the test data be shared? How will it be presented?

Staffing and Training Needs

Is there any training necessary for testers to complete the planned testing?

Responsibilities

Who is in charge? Roles? Assign accountability for the different stages of the plan.

Schedule

It’s important to make realistic and valid estimates of the required test plan timeline.

Planning Risks and Contingencies

Are there any risks associated with completing the project? Lack of personnel resources? Hardware availability? Potential changes?

Approval

Who is designated to acknowledge the project as complete and allow it to proceed onto the next level? This may differ from unit-level to master-level teams.

As you can see, creating a test plan is a relatively involved process that takes time, and likely multiple parties, to satisfy completely. However, having a clear plan from the outset of a testing process can pay dividends in organization, tracking, and efficiency.

That said, test plans are primarily a requirement of running test cases. One alternative to this is guided exploratory testing, which primarily utilizes manual, human testing. In this case, testing instructions can be written out briefly in plain English, highlighting broad to specific instructions surrounding a particular user flow or product that is being tested. You can read more about this type of testing here.