Test Plan – Software Testing Fundamentals

A TEST PLAN is a document describing software testing scope and activities. It is the basis for formally testing any software / product in a project.

ISTQB Definition

• test plan: A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice,and any risks requiring contingency planning. It is a record of the test planning process.
• master test plan: A test plan that typically addresses multiple test levels.
• phase test plan: A test plan that typically addresses one test phase.

Elaboration

Test Plan is influenced by the following factors:

• Organizational test policy and test strategy
• Software development life cycle model
• Scope of testing
• Availability of resources.

At the beginning of the project, the test plan can be a draft or with very little details. But, as the project progresses and more information becomes available, the test plan needs to be fleshed out. Test planning is a continuous activity and is performed throughout the product’s life cycle.

Types

Test plans can be of the following types:

• Master Test Plan: A single high-level test plan for a project / product that unifies all other test plans.
• Testing Level Specific: Test plans for each level of testing:
  • Unit Test Plan
  • Integration Test Plan
  • System Test Plan
  • Acceptance Test Plan
• Testing Type Specific: Test plans for specific types of testing like Performance Test Plan and Security Test Plan.

Test Plan Template

The format and content of a software test plan vary depending on the processes, standards, and test management tools being implemented. Nevertheless, the following format, which is based on IEEE standard for software test documentation, provides a summary of what a test plan can / should contain.

Test Plan Identifier:

• Provide a unique identifier for the document. (Adhere to the Configuration Management System if you have one.)

Introduction:

• Provide an overview of the test plan.
• Specify the goals / objectives.
• Specify any constraints.

References:

• List the related documents, with links to them if available, including the following:
  • Project Plan
  • Configuration Management Plan

Test Items:

• List the test items (software / products) and their versions.

Features to be Tested:

• List the features of the software / product to be tested.
• Provide references to the Requirements and/or Design specifications of the features to be tested.

Features Not to Be Tested:

• List the features of the software / product which will

  not

  be tested.

• Specify the reasons these features won’t be tested.

Approach:

• Mention the overall approach to testing.
• Specify the following:
  • Testing levels [if it’s a Master Test Plan],
  • Testing types
  • Testing methods

Item Pass / Fail Criteria:

• Specify the criteria that will be used to determine whether each test item has passed or failed testing.

Suspension Criteria and Resumption Requirements:

• Specify criteria to be used to suspend the testing activity.
• Specify what is required before testing can resume.

Test Deliverables:

• List test deliverables, and links to them if available, including the following:
  • Test Plan (this document itself)
  • Test Cases
  • Test Scripts
  • Test Data
  • Defect Reports
  • Test Reports

Test Environment:

• Specify the properties of test environment: hardware, software, network, etc.
• List any testing or related tools.

Estimate:

• Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

Schedule:

• Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.

Staffing and Training Needs:

• Specify staffing needs by role and required skills.
• Identify training that is necessary to provide those skills, if not already acquired.

Responsibilities:

• List the responsibilities of each team / role / individual.

Risks:

• List the risks that have been identified.
• Specify the mitigation plan and the contingency plan for each risk.

Assumptions and Dependencies:

• List the assumptions that have been made during the preparation of this plan.
• List the dependencies.

Approvals:

• Specify the names and roles of all persons who must approve the plan.
• Provide space for signatures and dates. (If the document is to be printed.)

Test Plan Guidelines

• Make the plan concise. Avoid redundancy and superfluousness. If you think you do not need a section that has been mentioned in the template above, go ahead and delete that section in your test plan.
• Be specific. For example, when you specify an operating system as a property of a test environment, mention the OS Edition / Version as well, not just the OS Name.
• Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
• Have the test plan reviewed a number of times prior to baselining it or sending it for approval. The quality of your test plan speaks volumes about the quality of the testing you or your team is going to perform.
• Update the plan as and when necessary. An out-dated and unused document stinks and is worse than not having the document in the first place.

But, a good Test Plan is not enough. You must also have good TEST CASES.

Last Updated on March 15, 2023 by STF