top of page

Project Management: Test Strategy vs Test Plan

by: Heather Todd

You scream, I scream, we all scream for testing?

In the world of software, testing comes in many flavors: Data migration/conversion, system configuration, customization unit testing, QA testing, End-to-end testing, Performance, Disaster Recovery, Parallel testing, and more. But why do we test? What is the difference between a test strategy and a test plan? This blog post answers those questions and more.

Why do we test?

We test to find problems that risks the value of the platform, or that risks the on-time, successful completion of any kind of development work. We test to help the business, managers, and developers decide whether the platform or custom feature is working as per the business requirements.

Approach to testing: Strategy vs Plan

The below table reflects the high-level difference between a test strategy and test plan.

Test Strategy

Goal A technique to follow and which module/features to test.How to test, when to test, and who will verify.

Objective Describes how testing needs to be executed (the approach).

Level Organization/Platform

Changeable No

Management Project Manager/Business AnalystTest Manager

Test Plan*

Goal How to test, when to test, and who will verify.

Objective Describes the scope, objective, and specific details on software testing.

Level Project

Changeable Yes

Management Test Manager

*Note, in a small project test strategy can be incorporated into the test plan.

Test Strategy

A test strategy is a high-level document that derives from the business requirements specification document. Usually, a project manager or a business analyst creates the test strategy to define software testing approaches used to achieve testing objectives. A test strategy document answers the following questions:

  • What is the product?

  • What part(s) of it should be tested?

  • How should they be tested?

  • When should testing begin?

  • What are the start/end criteria?

The main components of a test strategy are:

  • The scope of testing

  • Test objectives

  • Budget limitations

  • Communication and status reporting

  • Testing measurement and metrics

  • Defect reporting and tracking

  • Configuration management

  • Deadlines

  • Test execution schedule

  • Risk identification

Test Plan

A test plan is a document that describes what to test, when to test, how to test, and who will do the tests. It also describes the testing scope and activities. Usually, the Test Manager creates the test plan. If a smaller project, then the project manager or business analyst to create the test plan. The test plan includes the objectives of the tests to be run and helps control the risks. A good test plan should include the schedule for all necessary testing activities in order to control your team’s testing time. It also should define the roles of every team members so that everyone is clear about what is required of them. A test plan document should contain the following information:

  • Test plan identifier

  • Introduction

  • References (a list of related documents)

  • Test items (the product and its versions)

  • Features to be tested

  • Features not to be tested

  • Item pass or fail criteria

  • Test approach (testing levels, types, techniques)

  • Suspension criteria

  • Deliverables (Test Plan, Test Cases, Test Scripts, Defect/Enhancement Tracking system, Test Reports)

  • Test environment (hardware, software, tools)

  • Estimates

  • Schedule

  • Staffing and training needs

  • Responsibilities

  • Risks

  • Assumptions and Dependencies

  • Approvals


bottom of page