<Product Name> Test Plan <Version Number>

<Product Name> Test Plan

Product version: <version number>

Document version: <version number>

Company Confidential Product Name <Version Number> 1 of 11

<Product Name> Test Plan <Version Number>

Revision History

Pages
Version Date of Release Description of change Author
Affected

Company Confidential Product Name <Version Number> 2 of 11

<Product Name> Test Plan <Version Number>

Table of Contents

1.0 Introduction.

1.1 Purpose.
1.2 Product Overview.
1.3 Scope.
1.4 Document Reference.
1.5 Intended Audience.

2.0 Validation Strategy.

2.1 Unit Testing.
2.2 Integration Testing.
2.3 System Testing.
2.4 Regression Testing.
2.5 Performance Testing.
2.6 Production Environment Testing.
2.7 User Acceptance Testing.

3.0 Test Environment and Resource Requirements.

4.0 Effort and Schedules.

5.0 About <Your Product>.

6.0 Test Procedure.

7.0 Defect Reporting.

7.1 Defect Tracking Tool.
7.2 Defect Resolution Procedure.
7.3 Priority Level.
7.4 Status of Bugs.
7.5 Defect Reporting Form.
7.6 Test Bed.

8.0 Tools.

9.0 Deliverables.

10.0 Appendix.

Company Confidential Product Name <Version Number> 3 of 11

<Product Name> Test Plan <Version Number>

1.0 Introduction
1.1 Purpose
The purpose of this document is to describe the Validation strategies adopted for testing the
<Product Name> application.

1.2 Product Overview

In this section, provide overview of the product’s functional specifications that would be explained
in detail later

1.3 Scope
The scope of this document is to explain the Testing Strategies, Test Environment, and Resource
Usage for testing the <Product Name> application.

1.4 Document Reference

The following documents have been studied for designing the Testing activities.

1. <Product Name> Functional Specification Document v 1.0

1. <Product Name> Design Document v 1.0

1.5 Intended Audience

The audiences for this document include Project Leader, Team Members and Test Engineers.

2.0 Verification & Validation Strategies

The following Validation Strategies would be implemented for the testing of <Product Name>
product.

1. Unit Testing
2. Integration Testing
3. System Testing
4. Regression Testing
5. Performance Testing
6. Production Environment Testing (at R&D Center and at client site)
7. User Acceptance Testing

2.1 Unit Testing

Goal of Unit testing is to uncover defects using formal techniques like Boundary Value Analysis
(BVA), Equivalence Partitioning, and Error Guessing. Defects and deviations in Date formats,
Special requirements in input conditions (for example Text box where only numeric or alphabets
should be entered), selection based on Combo Box’s, List Box’s, Option buttons, Check Box’s
would be identified during the Unit Testing phase.
Test Cases would be written based on the design document for all the requirements mentioned in
the test conditions.
Test Conditions
• User Interface
• Boundary Value Analysis

Company Confidential Product Name <Version Number> 4 of 11

<Product Name> Test Plan <Version Number>

• Equivalence Partitioning
• Error Guessing

Entry Criteria
• Base lined design document
• Base lined code
• Base lined test plan document
• Unit test case document

Work Items
• Test execution

Exit Criteria
• Test execution report
• Unit testing review checklist

2.2 Integration Testing

During Integration Testing, behavior of the system on the whole is observed. Individual modules
are integrated and tested for the whole functionality.
Test Cases would be written based on the design document, for all the requirements mentioned in
the test conditions.

Test Conditions
• Behavior of Individual Modules.
• Integration between different modules

Entry Criteria
• Base lined design document
• Base lined Functional specification document
• Base lined code
• Base lined test plan document
• Unit test execution report
• Integration test case document

Work Items
• Test execution

Exit Criteria
• Test execution report
• Integration review checklist

2.3 System Testing

The goal of system testing is to uncover defects while integrating hardware and software system
to verify that the system meets its specified requirements.

Test Conditions
• Functionality of the application with respect to its behavior on the whole, with
compliance to its hardware and software.

Entry Criteria

Company Confidential Product Name <Version Number> 5 of 11

<Product Name> Test Plan <Version Number>

• Unit test review checklist

• Integration test review checklist
• Base lined test plan document
• Unit / Integration / System test case documents

Work Items
• Test execution

Exit Criteria
• Test execution report
• System review checklist

2.4 Regression Testing

The goal of Regression Testing is to observe the behavior of the system after certain rounds of
test phases.
Test cases / scenarios for the regression round would be derived from the unit and integration test
case documents.

Test Conditions
• Functionality of the application on the whole. (Refer Unit / Integration / System
Checklists).

Entry Criteria
• Unit test review checklist
• Integration test review checklist
• Base lined test plan document
• Unit / Integration test case documents

Work Items
• Test execution

Exit Criteria
• Test execution report
• Regression review checklist

2.5 Performance Testing

The performance of the application under standard conditions is tested during this phase.
Test scenarios and test cases will be developed for all the performance parameters.

Test Conditions
• Performance of the application at stipulated parameters

Entry Criteria
• Base lined test plan document
• Performance test case / scenario document
• Performance parameter specification list

Work Items
• Test execution

Company Confidential Product Name <Version Number> 6 of 11

<Product Name> Test Plan <Version Number>

Exit Criteria
• Test execution report
• Performance review checklist

2.6 Production Environment Testing

The behavior of the application after the standard setup is made in the production environment
and at the live environment is tested during this phase.
Test cases and scenarios would be derived from Unit / Integration / System / Regression /
Performance test case documents.

Test Conditions
• The behavior of the completely built application at the production and the client
site. (Refer the checklists for Unit / Integration / System and User Acceptance
Testing).

Entry Criteria
• Base lined design document
• Base lined Test plan document
• Compiled EXE file of the application
• Unit / Integration / Regression / Performance Test execution reports

Work Items
• Test execution

Exit Criteria
• Test execution report
• Production Environment review checklist

2.7 User Acceptance Testing

User Acceptance Testing (UAT) is performed to test the application on the whole and its behavior
in the live environment based on the clients requirements.
Test cases and scenarios would be derived from the Unit / Integration / Regression / Performance
test case documents and also the Software Requirements Document.

Test Conditions
• The behavior of the application as per the client’s requirements.
Entry Criteria
• Base lined software requirement document
• Base lined design document
• Base lined test plan document
• Unit / Integration / Regression / Performance / Production environment test
execution reports

Work Items
• Test execution

Exit Criteria
• Test execution report
• UAT review checklist

Company Confidential Product Name <Version Number> 7 of 11

<Product Name> Test Plan <Version Number>

3.0 Test Environment and Resource Requirements.

The Requirements and Resources required for carrying out the Verification and Validation
activities are given below.

Phase Resources Requirements

Unit Testing.
Integration Testing.
Regression Testing.
Performance Testing.
Production Environment
Testing (On site and Client
site).
User Acceptance Testing.

4.0 Effort and Schedules.

The below table describes the effort and the schedules for the testing activities.

Activity Start Date End Date Duration

Unit Testing
Integration Testing
Regression Testing
Performance Testing
Production Environment Testing
User Acceptance Testing
Note: The Schedule for the Testing Activity is synchronized with the Development Test Plan. Any
changes made to the Development Plan would reflect in the schedules of the Testing activity.

5.0 <Product>
Give a brief description of the working of the product.

NOTE: This is optional. If you wish that this section should be there, keep it. Else, you
can ignore this section.

6.0 Test Approach

The Testing approach for <Product Name> application would follow <Describe the test
approach>
The primary objective of Testing is to discover errors in the system at various levels and stages.

Company Confidential Product Name <Version Number> 8 of 11

<Product Name> Test Plan <Version Number>

Test cases thus generated will be executed and deviation in functionality will be reported as errors
for correction.

7.0 Defect Tracking & Reporting

Bugs and suggestions identified during any phase of testing would be reported immediately. The
basis of identification of bugs and the classification of bugs is mentioned in the table below:

Category Description
Severe Functionality not working.
Major Serious effect to the functionality.
Minor Minor deviation in the functionality.
Cosmetic Errors with respect to User Interface.
Suggestion Suggestion for improvement.

The errors identified would be reported to the Development Team through a Defect Tracking Tool.

7.1 Defect Tracking Tool

We would be using <Bug Tracking Tool name>. All the Development Team Members and Test
Engineers would be given user privileges to log in any type of error identified by them.

7.2 Defect Resolution Procedure

Defects logged on to the defect tracking tool should be resolved at the earliest. The person, who
identifies the bug, logs it on to the <Tool Name> and intimates the person who is assigned the
job to fix the bug via e-mail.

Regular meetings between the Test team and the Development team would be organized to have
continuous updates on the status.

7.3 Priority Level

The priority level for the errors reported will be rated as given below:

Level Description
Must Fix Fix the bug at the Immediately.
Should Fix Important, Fix at the earliest.
Fix when have time Fix the bug when time permits.
Low Priority Not exactly a bug.

7.4 Status of Bugs

The status of bugs will have four options. They are briefed below:

Status Description
Open The error reported is open.

Company Confidential Product Name <Version Number> 9 of 11

<Product Name> Test Plan <Version Number>

Resolved The error is resolved.

Close The error is re-tested and closed.
Re-Open The error is re-opened.

When the test engineer opens a bug, the developer resolves the bug and changes the status of
the error to “Resolved”. The test engineer re-tests the error and Closes. If the error is repeated
while in any phase of testing, the error would be re-opened.

7.5 Items to be filled in the Bug Report

In this section mention the fields in the bug report form and how one should log in the bugs.

Item Description

7.6 Test Bed

The testing of <Product Name> application is carried out on a separate test bed, different from
the development environment. The original database is replicated here for the purpose. Special
Servelets have been written to populate the test data into the test bed. The test bed is created
using MS-Access. The list of tables created in the test bed can be referred in Appendix <Give the
appendix number>

8.0 Tools
The following tools would be used by the team members during the course of the project.

Purpose Tool
Defect Tracking Tool
Configuration Management
Scheduling

9.0 Deliverables
The following documents would be maintained by the Test team.

1.0 Test Plan.

2.0 Test Schedule.
3.0 Test Case Documents.
4.0 Test Execution Reports.
5.0 Weekly Status Reports.

Company Confidential Product Name <Version Number> 10 of 11

<Product Name> Test Plan <Version Number>

The Test Schedule would be maintained in a Microsoft Project file with reference to the Test Plan.
The schedule will be affected whenever there is a change in the schedules of the Project Plan.

10.0 Appendix
Enclose here any appendices you need.

Company Confidential Product Name <Version Number> 11 of 11