Test plan & test strategy are same..? or they are seprately prepared...?Ple

Test plan & test strategy are same..? or they are seprately
prepared...?Please clarify

Question Posted / harishkamu

1 Answers
4342 Views
I also Faced
E-Mail Answers

Test plan & test strategy are same..? or they are seprately prepared...?Please clarify..

Answer / ronh

The Test Plan is the "Overall" description about how the
testing department intends on handling the application
testing phase. The Test Strategy is a subset of the Test
Plan explaining "how" the application will be tested.

[Company Logo]

Test Plan
Version 0.0

Description of Project

DOCUMENT NO:
VERSION:

CONTACT: [Name]
EMAIL:

DATE: 3/31/2009

Distribution is subject to copyright.

Disclaimers
The information contained in this document is the
proprietary and exclusive property of [Company Name] except
as otherwise indicated. No part of this document, in whole
or in part, may be reproduced, stored, transmitted, or used
for design purposes without the prior written permission of
[Company Name].
The information contained in this document is subject to
change without notice.
The information in this document is provided for
informational purposes only. [Company Name] specifically
disclaims all warranties, express or limited, including,
but not limited, to the implied warranties of
merchantability and fitness for a particular purpose,
except as provided for in a separate software license
agreement.
Privacy Information
This document may contain information of a sensitive
nature. This information should not be given to persons
other than those who are involved in the Project Name
project or who will become involved during the lifecycle
Trademarks
[Trademarks are added here]
Version History

REVISION CHART
Version Author(s) Description of Version Date
Completed

Document Owner

The primary contact for questions regarding this document
is:
Author:
Project Name
Phone:
Email:
Document Approval

Document Name:
Publication Date:
Contract Number:
Project Number:
Prepared by:

Approval: __________________________
Name and Organization

Concurrence: _________________________
Name and Organization

Table of Contents
1 Introduction 6
1.1 Objectives 6
1.2 Document Overview 6
1.3 Testing Strategy 6
1.4 Scope 7
1.5 Reference Material 7
1.6 Relationship to Other Plans 7
1.7 Key Stakeholders 7
1.8 Points of Contact 8
1.9 Methodology, Tools, and Techniques 8
1.10 Policies, Directives and Procedures 8
2 Test Items 9
2.1 Program Modules 9
2.2 Documentation Testing Procedures 9
2.3 Application Testing Procedures 9
2.4 Features Within Scope 9
2.5 Features Outside of Scope 10
3 Test Entrance Criteria 11
3.1 Documentation 11
4 Test Planning 12
4.1 Unit Testing 12
4.2 Integration Testing 12
4.3 Conversion Testing 12
4.4 Interface Testing 12
4.5 Security Testing 12
4.6 Recovery Testing 13
4.7 Performance Testing 13
4.8 Regression Testing 13
4.9 Acceptance Testing 13
4.10 Beta Testing 13
5 Pass / Fail Criteria 14
5.1 Testing Error Levels 14
5.2 Suspension Criteria 15
5.3 Resumption Criteria 15
6 Test Exit Criteria 16
6.1 Sample Software Release Form 16
7 Project Management 17
7.1 Test Deliverables 17
7.2 Testing Tasks 17
7.3 Risk Assessment 18
7.4 Constraints 18
7.5 Issues 18
7.6 Assumptions 19
7.7 Dependencies 19
8 Project Team 20
8.1 Roles and Responsibilities 20
8.2 Responsibilities 20
8.3 Resources 20
8.4 Training 20
9 Environmental Requirements 21
9.1 Hardware 21
9.2 Software 21
9.3 Security 22
9.4 Tools 22
9.5 Documentation 22
10 Plan Approvals 23
10.1 Sign-Off Criteria 23
11 Appendices 24
11.1 Glossary of Terms 24
11.2 Acronyms and Abbreviations 24
12 Appendix B — Sample Test Case 25

Index of Tables

Table 1 — Schedule 17
Table 2 — Testing Tasks 17
Table 3 — Risk Assessment 18
Table 4 — Constraints 18
Table 5 — Issues 18
Table 6 — Assumptions 19
Table 7 — Dependencies 19
Table 8 — Roles and Responsibilities 20
Table 9 — Hardware 21
Table 10 — Software 21
Table 11 — Tools, Techniques and Methodologies 22
Table 12 — Documentation 22
Table 13 — Sign-off Criteria 23
Table 14 — Glossary of Terms 24
Table 15 — Acronyms and Abbreviations 24

1 Introduction
The Test Plan outlines the scope, approach, resources, and
schedule of all testing activities. It identifies the items
and features to be tested; types of testing; resource
requirements; and an approach to project management.
1.1 Objectives
Describe the high-level test plan objectives, e.g. products
to be delivered, major activities, products, milestones,
resources, and schedules.

1.2 Document Overview
Outline the main sections in this document, for example:

• Chapter 1 – Describe the contents of this chapter.
• Chapter 2 – Describe the contents of this chapter.
• Chapter 3 – Describe the contents of this chapter.
• Chapter 4 – Describe the contents of this chapter.
• Chapter 5 – Describe the contents of this chapter.

1.3 Testing Strategy
For each level of testing, prepare a separate test plan
with the following set of deliverables:
• Features to be tested
• Items to be tested
• Management and technical approach
• Milestones
• Pass / Fail criteria
• Purpose for testing
• Risks, assumptions, and constraints
• Roles and responsibilities
• Schedules
1.4 Scope
Describe the scope (i.e. parameters) for the test plan(s).
Also, list any areas specifically excluded from the plans.
Outline how scheduled and unscheduled updates to the
Software Test Plan will be managed.
 Separate Test plans must be developed for each
level of product testing.

1.5 Reference Material
Identify all documents and sources referenced in the Test
Plan. Cross-references to the following documents (where
applicable) is required for the high-level test plan:
• Configuration Management Plan
• Company policies and procedures
• Project authorization
• Project Plan
• Quality Assurance Plan
• Standards

1.6 Relationship to Other Plans
Describe this document’s relation to other plans, such as:
• Program Management Plan
• Configuration Management Plan
• Software Quality Assurance Plan

1.7 Key Stakeholders
Outline the project’s key stakeholders, for example:
• John Q Public, the client’s representative
• Jane Q Public, Head of IT Dept.
• James Q Public, Head of QA Dept.

1.8 Points of Contact
Outline the main points of contact for this plan, i.e. for
troubleshooting purposes.
Include the type of contact, contact name, department,
telephone number, and e-mail address.

1.9 Methodology, Tools, and Techniques
Describe the software tools (or techniques) required for
performing the respective tasks, e.g. software for managing
changes requests.

1.10 Policies, Directives and Procedures
Outline the policies and procedures that apply to this
document. Identify any external constraints or requirements
placed on this document by policies, directives, or
procedures.

2 Test Items
Identify the test items that will be covered in this plan.
Refer to the following documents where appropriate:
• Design specification
• Installation guide
• Operations guide
• Requirements specification
• Users guide
• Verification plans

2.1 Program Modules
Describe how each module will be tested.

2.2 Documentation Testing Procedures
Describe how the user documentation will be tested to
ensure that it is correct, complete, and comprehensive.

2.3 Application Testing Procedures
Describe how the application will be tested to ensure that
it can run and supported in a production environment.

2.4 Features Within Scope
Identify all software features to be tested. Identify the
design specifications associated with each feature.

2.5 Features Outside of Scope
Identify all features that will not be tested, along with
the reasons for this decision, e.g. timelines, available
resources etc.

3 Test Entrance Criteria
To produce software that meets client needs, certain items
must be in place prior to the software entering the QA
testing phase. This document outlines the items that must
be in place to promote software from the development group
to Quality Assurance.

3.1 Documentation

The following articles of documentation should be developed
and be available prior to testing:

• Requirements specification
• Design specification
• Installation / Deployment guide
• Operations guide
• Users guide
• QA Test Plan
• Verification plans
• QA Test Cases

Describe how the user documentation will be tested to
ensure that it is correct, complete, and comprehensive

The following articles of programming should be developed
and be available prior to testing:

• Front End Code
• Back End Code
• Operational Screens
• Database Tables / Fields / Records
• System Security
• System Software and Hardware Requirements

Describe how the application will be tested to ensure that
it can run and supported in a production environment

4 Test Planning
Identify the different types of testing and the methods and
criteria for performing the test activities. For each level
of testing, prepare a test plan and the appropriate set of
deliverables.

4.1 Unit Testing
Describe how Unit Testing will be conducted to verify the
implementation of each software element or collection of
software elements.

4.2 Integration Testing
Describe how Integration Testing will be conducted on
software and hardware elements, until the entire system has
been integrated.
This ensures that the design objectives are met and that
the software complies with operational requirements.
 Integration Testing is also known as System Testing.

4.3 Conversion Testing
Describe how Conversion Testing will be conducted to ensure
that all data elements (and historical data) are converted
from the previous system format to the new system format.

4.4 Interface Testing
Describe how Interface Testing will be conducted to ensure
that the application operates efficiently outside the
application boundary.

4.5 Security Testing
Describe how Security Testing will be conducted so that the
application systems control and auditability features are
functional.

4.6 Recovery Testing
Describe how Recovery Testing will be conducted to ensure
that the application’s restart, backup, and recovery
facilities operate as designed.

4.7 Performance Testing
Describe how Performance Testing will be conducted to
ensure that the application performs to customer
expectations (e.g. response time).

4.8 Regression Testing
Describe how Regression Testing will be conducted to ensure
that changes to the application have not adversely affected
previously tested functionality.

4.9 Acceptance Testing
Describe how Acceptance Testing will be conducted to ensure
that the system satisfies the acceptance criteria.

4.10 Beta Testing
Describe how Beta Testing will be conducted to detect
application faults, failures, and defects.

5 Pass / Fail Criteria
Identify the Pass/Fail criteria, i.e. whether an item has
passed or failed its test.
5.1 Testing Error Levels

Error Severity Level Description
1 Highest Level 1 –
Program aborts and cannot continue.
Testing must stop until the error has been corrected.
These errors are of the highest priority and should be
corrected by the programmers as soon as possible.
In some companies, these errors are reserved for problems
that must be fixed within 24 hours.
2 Level 2 –
A program module aborts and the module cannot continue to
be tested.
The rest of the program is operational and testing may
continue on other modules while the error is being
corrected.
In some companies, these errors are reserved for problems
that must be fixed within 48 hours.
3 Level 3 –
A program module aborts however there is a work around.
Testing can continue using the work around until the actual
program error has been corrected.
In some companies, these errors are reserved for problems
that must be fixed within 1 week.
4 Lowest Level 4 –
This is reserved for non-program functioning errors such as
cosmetic items on the screen. The program and it’s modules
are functioning as designed however, items with this
severity level may be items that are desired fixes and will
be determined to be in the current release or reserved for
later releases.
In some companies, these errors are reserved for problems
that may be fixed in the current release or saved for
correction in a future release.

5.2 Suspension Criteria
Identify the criteria used to suspend all (or a portion) of
the testing activity.

If a Severity Level 1 problem occurs while in the testing
phase, testing will cease until the problem has been
corrected.

5.3 Resumption Criteria
Identify the conditions required to resume testing
activities after suspension.

To resume testing, the programmers will certify that the
Severity Level 1 problem has been corrected and that the
software is ready to reenter the testing phase.

6 Test Exit Criteria
Identify the conditions required to approve test results.

To approve software for release to production it must
comply with the following testing criteria:
The software cannot have any Severity Level 1 errors.
The software cannot have any Severity Level 2 errors.
The software may be released with Severity Level 3 or 4
errors if the work around and the cosmetic errors are
documented for the client, and if the software has been
determined to be non-threatening to the client if installed
into production.
In all cases, all Severity Level problems will attempt to
be fixed by developers prior to release of the software to
any client.
The ultimate decision on whether to release software to a
production environment will be determined by the QA
Department Manager and the Business Analyst. Software will
not be deployed to production without both individuals
signing a release form that states that the software has
met the testing release criteria and that the software can
be deployed.

6.1 Sample Software Release Form

Date:

The following software:
_______________________________________________ has been
tested by the [Company Name] Quality Assurance Department
and meets the criteria to be deployed into production.

A complete Test Exit Report is on file with the [Company
Name] Quality Assurance Department and may be reviewed upon
request.

------------------------------------------------------------
---------------- --------------------------
QA Department Manager Signature Date

------------------------------------------------------------
---------------- --------------------------
Business Analyst Signature
Date
7 Project Management
7.1 Test Deliverables
Identify the deliverables from the test process, including
report logs, incident reports, and summary reports.
Prepare a high-level schedule for each testing task.
Identify the resources required for each activity and
proposed contingencies should these individuals need to be
replaced.

Deliverable Role Responsibility Start Date End
Date

Table 1 — Schedule
7.2 Testing Tasks
Identify the tasks necessary to prepare testing activities,
including inter-related tasks.

Ref Task Inter-related Tasks
1.
2.
3
Table 2 — Testing Tasks

7.3 Risk Assessment
Identify the risks associated with the test plan, including
contingency strategies.

Risk Low Med. High Contingency

Table 3 — Risk Assessment
7.4 Constraints
Identify any business or technology constraints that may
impact the plan, e.g. resources, schedules, or budgetary
issues.

Ref Constraint Action
1.
2.
3
Table 4 — Constraints

7.5 Issues
Identify issues that may affect the development and
operation of the test plan, e.g. communications, security,
training.

Ref Issue Action
1.
2.
3
Table 5 — Issues

7.6 Assumptions

Identify all assumptions regarding the test plan.

Ref Assumption Impact
1.
2.
3
Table 6 — Assumptions

7.7 Dependencies

Identify the main dependencies regarding the plan.

Ref Dependency Action
1.
2.
3
Table 7 — Dependencies
8 Project Team
8.1 Roles and Responsibilities
Describe each person(s) role and responsibility during the
test plan.

Name Role Responsibility % Committed

Table 8 — Roles and Responsibilities
8.2 Responsibilities
Identify the user groups responsible for all aspects of
test plan(s) activities, such as developers, testers,
technical writers, and end-users.

8.3 Resources
Identify the resources required for performing each testing
tasks.

8.4 Training
Describe the training requirements for users, testers, and
other personnel. Outline the content and scheduling of
training courses for personnel.

9 Environmental Requirements
Describe the test environment including the physical
characteristics, communications, levels of security, and
software testing tools.

9.1 Hardware
Identify the hardware and network requirements for testing
activities.

Ref Hardware Purpose
1.
2.
3
Table 9 — Hardware
9.2 Software
Identify the software requirements for testing activities.

Ref Software Purpose
1.
2.
3
Table 10 — Software

9.3 Security
Identify the security and asset protection requirements for
testing activities.

9.4 Tools
Identify software tools, techniques, and methodologies used
in the testing efforts. Describe the purpose of each tool.

Ref Tool Purpose
1.
2.
3
Table 11 — Tools, Techniques and Methodologies

9.5 Documentation
Identify any documentation required to support testing
activities.

Ref Documentation Owner
1.
2.
3
Table 12 — Documentation

10 Plan Approvals
Identify the plan approvers, including name, signature and
date of approval.

10.1 Sign-Off Criteria
Identify individuals authorized to sign off the plan.

Name Role Signature Date

Table 13 — Sign-off Criteria
11 Appendices
Attach any addition information that supplements the test
plan.

11.1 Glossary of Terms
List and define all terms that establish meaning within the
context of the plan.

Term Meaning

Table 14 — Glossary of Terms
11.2 Acronyms and Abbreviations
Provide a list of acronyms and abbreviations used in this
document and the meaning of each.

Acronym Meaning

Table 15 — Acronyms and Abbreviations

12 Appendix B — Sample Test Case
The following is a sample test case template. This table
describes the content of the fields in the test case form

Test Case Template
Project Name Test Date
Test Case Description
Test Scenario #
Version / Build #
Module Under Test Execution Retry #
Test Requirement # Case #
Created by
Test Environment
Setup for Test
Pre-conditions
Tested by
Step Action Expected Results Pass / Fail
Failure Results
1
2
3
4

Is This Answer Correct ?

0 Yes

0 No

Post New Answer