<<Project Name>>

Test Plan
Customer Name
Directions for using template:
Read the Guidance (Arial blue font in brackets) to understand the information that
should be placed in each section of this template. Then delete the Guidance and
replace the placeholder within <<Begin tet here!! with "our response. There ma" be
additional Guidance in the Appendi of some documents# which should also be
deleted once it has been used.
$ome templates ha%e four le%els of headings. The" are not indented# but can be
differentiated b" font t"pe and si&e:
'eading ( ) Arial Bold (* font
'eading + ) Arial Bold ,talic (- font
'eading . ) Arial Bold (. font
'eading . ) Arial Bold ,talic (+ font
/ou ma" elect to indent sections for readabilit".
Author
Author 0osition
1ate
2ersion: (.3
345+(5+3(-

2002 Microsoft Corporation. All rights reserved.
The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not
be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accurac of an
information presented after the date of publication.
This document is for informational purposes onl. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR
IMPIE!, IN T"IS !OC#MENT$
Microsoft and !isual Basic are either registered trademarks or trademarks of Microsoft in the "nited #tates and$or
other countries.
345+(5+3(-

Revision & Sign-off Sheet
6hange Record
1ate Author 2ersion 6hange Reference
Re%iewers
7ame 2ersion Appro%ed 0osition 1ate
1istribution
7ame 0osition
1ocument 0roperties
,tem 1etails
1ocument Title Test 0lan
Author
6reation 1ate
8ast 9pdated
345+(5+3(-

Table of Contents
$ummar"..........................................................................................................................
:b;ecti%es........................................................................................................................
Test Approach < Assumptions........................................................................................
=a;or Test Responsibilities............................................................................................-
>eatures and >unctionalit" to Test..................................................................................-
?pected Results of Tests...............................................................................................@
1eli%erables....................................................................................................................@
Test 1ocumentation....................................................................................................@
Test 1ata.....................................................................................................................@
,nteractions with :ther :rgani&ations............................................................................@
Testing 0rocedures and Aalkthrough.............................................................................*
Testing $etup..............................................................................................................*
Testing 0rocedures......................................................................................................*
Testing Aalkthrough...................................................................................................*
Tracking and Reporting $tatus.......................................................................................*
Test Resource ReBuirements..........................................................................................4
?n%ironmental 7eeds.................................................................................................4
$taffing < Training 7eeds..........................................................................................4
Test Tool ReBuirements..............................................................................................4
Bug Reporting Tools and =ethods.................................................................................4
Bug Reporting Tool $trateg"......................................................................................4
Bug 6lassification $trateg"........................................................................................C
Triage $trateg"...........................................................................................................C
Bug 6losure 6riteria...................................................................................................C
$chedules........................................................................................................................C
Risks < 1ependencies....................................................................................................C
:pen ,ssues.....................................................................................................................D
Appendi......................................................................................................................(3
Appendi A ) Test 6ase $pecification ?ample......................................................(3
345+(5+3(- 3

%Intro%uct&on to t'e Tem(late
&escription' The Test (lan describes the strateg and approach used to plan,
organi)e, and manage the pro*ect+s testing activities. ,t identifies testing ob*ectives,
methodologies and tools, e-pected results, responsibilities, and resource
re.uirements. This document is the primar plan for the testing team.
)ust&*&cat&on+ A Test (lan ensures that the testing process will be conducted in a
thorough and organi)ed manner and enable the team to determine the stabilit of the
solution. A continuous understanding of the solution+s status builds confidence in
team members and stakeholders as the solution is developed and stabili)ed.
/Team Role Pr&mar,+ Test is responsible for the creating the Test (lan. This plan
outlines the strateg the team will take for the solution+s testing. The Test 0ole is
responsible for setting the .ualit e-pectations and incorporating those into the
testing plan.
Team Role Secon%ar,+ Pro-ram Mana-ement participates in developing the test
plan b ensuring that the solution re.uirements are met, the correct components are
tested, and appropriate strategies are adopted for bug reporting and resolution.
!e.elo(ment needs to understand how their work will be tested and how the bugs
will be reported, assigned, resolved, and verified. #ser E/(er&ence verifies that the
Test (lan contains the strategies and methods to test accessibilit, usabilit, and
interface features.12
345+(5+3(-

Summar,
%!escr&(t&on+ (rovide an overall summar of the contents of this document.
)ust&*&cat&on+ #ome readers ma need to know onl the highlights of the plan, and
summari)ing creates that user view. ,t also enables the full reader to know the
essence of the document before the e-amine the details.2
<<Begin tet here!!
O0ject&.es
%!escr&(t&on+ The 3b*ectives section identifies the Test (lan+s ob*ectives. The
following list of ob*ectives ma appl to the pro*ect. ,nclude an additional ob*ectives
specific to the pro*ect.
To identif the activities re.uired to prepare for and conduct testing
To define the test scope, strateg and methodolog to be used for the test
To identif configuration controls and metrics
To define metrics and status reporting
To identif responsibilities for the tasks included in the plan
To define the test tools and the environment needed to conduct the test
To identif test interactions with other organi)ations
To identif test customers and deliverables
To identif the ma*or testing milestones
To define the sources of information used to prepare the plan
)ust&*&cat&on+ ,dentifing ob*ectives ensures that the plan+s authors have carefull
considered the situation and solution and created an appropriate testing approach.2
<<Begin tet here!!
Test A((roac' 1 Assum(t&ons
%!escr&(t&on+ The Test Approach 4 Assumptions section describes at a high level the
approach, activities, and techni.ues 5including techni.ues for designing tests6 to be
followed in testing the solution. ,f different approaches are re.uired for the solution+s
various components, this section should define which components would be tested
b each approach.
This section also describes the processes 5criteria and techni.ues6 that will be used
to verif that the testing approach chosen will effectivel guarantee the re.uired
degree of test completeness. A process could be as simple as re.uiring all
appropriate groups to review, comment, and sign off on the document. A process
345+(5+3(- +

could be more comple-, re.uiring the use of tools to verif statement and path
coverage.2
<<Begin tet here!!
Major Test Res(ons&0&l&t&es
%!escr&(t&on+ The Ma*or Test 0esponsibilities section identifies the teams and
individuals who will be both managing and e-ecuting the testing process. This
information could be placed in a matri- that identifies each ke element of the testing
process and the people who will participate in that process.2
<<Begin tet here!!
Features an% Funct&onal&t, to Test
%!escr&(t&on+ The 7eatures and 7unctionalit to Test section identifies at a high level
all features and functionalit or all user and usage functionalit that will be tested.
#ufficient detail is re.uired to allow plan reviewers to determine if an ma*or area,
feature, or test modes are being left out or insufficientl covered. 7or documentation
testing 5e.g. procedures or guidelines 8 such as installation and configuration
methods6, list the documents b name and indicate their intended audience and
e-pected content. Briefl describe the standards that will be emploed in verifing
their usabilit, correctness, and completeness. #ome e-amples of the information to
be included in this section are
#pecific features to be tested
9hether testing will include unsupported functionalit
The tpes of facilit 5feature6 testing to be performed
The tpes of error testing to be performed
The tpes of stress$load testing to be performed
The tpe of usabilit testing to be performed
The tpe of reliabilit testing to be performed
The tpe of recover testing to be performed
The tpe of manageabilit testing to be performed
The tpe of compatibilit$migration testing to be performed
The tpe of securit testing to be performed
The tpes of software and hardware to be emploed if testing is to be
performed over multiple software and hardware configurations 5configuration
testing6
This section ma be developed using a table that indicates for each feature, function,
user, or usage function 5hori)ontal headings6, the tpes of testing applicable to each
5vertical left headings6.2
345+(5+3(- .

<<Begin tet here!!
E/(ecte% Results o* Tests
%!escr&(t&on+ The :-pected 0esults of Tests section describes what results should
be demonstrated from the tests. This information should include e-pectations b both
b the solution team and the tester5s6. This section should also define if the results
must be e-actl as anticipated or if a range of results is acceptable.2
<<Begin tet here!!
!el&.era0les
%!escr&(t&on+ The &eliverables section describes the materials that must be made
available or created in order to conduct the tests and that will be developed from the
tests to describe test results.2
<<Begin tet here!!
Test Documentation
%!escr&(t&on+ The Test &ocumentation section itemi)es all documentation that
records the activities of the testing process 5procedures, configurations, plans, action
items, etc.6. 7or each document, describe the specific information each will contain.
The set of documents ma include'
Test bed configurations
Test logs
(eriodic test status reports
,nput to release retrospective
Test results summar report at the completion of testing
7inal release note documentation2
<<Begin tet here!!
Test Data
%!escr&(t&on+ The Test &ata section identifies an e-isting test data that will be used
during the testing, either as is or with modifications. ,t also identifies an test data that
will need to be created for testing.2
<<Begin tet here!!
Interact&ons 2&t' Ot'er Or-an&3at&ons
%!escr&(t&on+ The ,nteractions with 3ther 3rgani)ations section identifies all
interfacing organi)ations that will participate in the testing. ,t describes the normal
345+(5+3(- -

interactions that will take place during the test process between the primar test team
and all other participating organi)ations. This should include a description of the tpe
of support e-pected to$from each interfacing organi)ation.
4Team Role Pr&mar,+ Pro-ram Mana-ement will manage these organi)ational
interfaces as the have a broad view of the pro*ect.
Team Role Secon%ar,+ Test52
<<Begin tet here!!
Test&n- Proce%ures an% Wal6t'rou-'
%!escr&(t&on+ The Testing (rocedures and 9alkthrough section provides a general
description of the steps the tests will go through to ensure .ualit tests.2
Testing Setup
%!escr&(t&on+ The Testing #etup section identifies the approach and procedures that
will be used for the initial phase of the test. This approach should define the steps of
the set up process. The set up process should include the staging re.uirements for
the testing and procedures to initiali)e the testing matri-.2
<<Begin tet here!!
Testing Procedures
%!escr&(t&on+ The Testing (rocedures section describes the detailed steps to be
followed b testers during the testing ccle. ,t should include a description of points
where testing is suspended for documentation of results, e-pectations on re;
initiali)ation of the environment, and tests that are to be performed in se.uence.2
<<Begin tet here!!
Testing Walkthrough
%!escr&(t&on+ The Testing 9alkthrough section describes how the planned testing
procedures will be reviewed to ensure .ualit. The walkthrough identifies who will
participate, what specificall will be reviewed, and how the walkthrough will be
conducted.2
<<Begin tet here!!
Trac6&n- an% Re(ort&n- Status
%!escr&(t&on+ The Tracking and 0eporting #tatus section defines what information
test team members will communicate during the testing process. ,t defines the
specific test status information that will be created and distributed. This normall
includes status information on each test case 5percent planned, developed,
automated, e-ecuted, passed, failed, and blocked6 and the probabilit of completing
the test ccle on schedule.2
<<Begin tet here!!
345+(5+3(- @

Test Resource Re7u&rements
%!escr&(t&on+ The Test 0esource 0e.uirements section identifies the environmental
conditions, staffing and training, and tools needed to conduct the tests successfull.2
Environmental eeds
%!escr&(t&on+ The :nvironmental <eeds section itemi)es all supplies re.uired for
testing and an au-iliar support tasks. This section should be broken into separate
subsections devoted respectivel to the hardware, software, data resources and
documentation re.uired for testing.
An resource;sharing re.uirements between releases and among testers should be
described here. ,f a separate integration test environment is not planned, then the
sharing of resources between integration and sstem$documentation testing should
be described as well. ,f a separate solution test environment is not planned, then the
sharing of resources between sstem$documentation and solution testing should also
be described.2
<<Begin tet here!!
Staffing & Training eeds
%!escr&(t&on+ The #taffing 4 Training <eeds section identifies the staff necessar to
accomplish the test effort. ,t should also identif if these re.uirements are e-pected to
var over the life of the test ccle. #taff re.uirements should be articulated b tpe
5skill area6 and number 5if more than one6. ,f staff will re.uire additional training, this
section should describe those needs and indicate how the will be met.2
<<Begin tet here!!
Test Tool Re!uirements
%!escr&(t&on+ The Test Tool 0e.uirements section describes an additional
hardware, tools, and$or simulators that are needed to support testing the solution.
This should include information on where the tools are located, whether e-isting tools
need modification, or if new tools must be developed.2
<<Begin tet here!!
8u- Re(ort&n- Tools an% Met'o%s
%!escr&(t&on+ The Bug 0eporting Tools and Methods section describes the overall
bug reporting strateg and methodolog. ,t also defines what will .ualif as a bug in
the code, product features, documentation, etc.2
"ug Reporting Tool Strateg#
%!escr&(t&on+ The Bug 0eporting Tool #trateg section identifies the bug reporting
tool standards and strateg for implementation.2
<<Begin tet here!!
345+(5+3(- *

"ug Classification Strateg#
%!escr&(t&on+ The Bug Classification #trateg section defines the process that will be
used to classif bugs. This should include the categories of bugs and how the will be
.uantified. ,f a tool or spreadsheet is planned, include a visual image of the tool
metrics that demonstrates how bugs will be .uantified and classified.2
<<Begin tet here!!
Triage Strateg#
%!escr&(t&on+ The Triage #trateg section describes how bugs will be triaged for
resolution after .uantification and classification. ,t describes the criteria for assigning
a bug to immediate resolution versus placing it in a priorit .ueue.2
<<Begin tet here!!
"ug Closure Criteria
%!escr&(t&on+ The Bug Closure Criteria section identifies the criteria that will be used
to determine that a bug is resolved. ,t also describes the resolution path to ensuring
that a bug is closed and has sign;off.2
<<Begin tet here!!
Sc'e%ules
%!escr&(t&on+ The #chedules section identifies the ma*or test ccles, tasks,
milestones, and deliverables. ,t also describes who is responsible for each test ccle
and its tasks. ,n addition, it identifies the e-pected start and completion date for each
test ccle and the tasks within that ccle. This section should identif all tasks that will
re.uire coordination with other groups or involve deliverables to or from outside
organi)ations.
)ust&*&cat&on+ The test schedule will be incorporated into the Master (ro*ect (lan.2
<<Begin tet here!!
R&s6s 1 !e(en%enc&es
%!escr&(t&on+ The 0isks 4 &ependencies section identifies three items' assumptions,
risks, and dependencies. The assumptions are those that have been made while
developing the test plan. The risks are those that arise from either the assumptions or
that are anticipated during the testing process. 7or each risk, indicate the probable
impact if the assumption turns out to be incorrect, and the measures emploed to
correct the situation. &ependencies include things such as the development plan and
functional specifications that will help create details for the test plan procedures.
)ust&*&cat&on+ ,dentifing risks earl enables the team to begin managing those risks.
<<Begin tet here!!
345+(5+3(- 4

O(en Issues
%!escr&(t&on+ The 3pen ,ssues section identifies an ke concerns and tasks that
need to be followed up on in order to ensure the plan+s completeness.2
<<Begin tet here!!
345+(5+3(- C

A((en%&/
$ppendi% $ & Test Case Specification E%ample
%!escr&(t&on+ (rovide an e-ample of a Test Case #pecification.2
<<Begin tet here!!
345+(5+3(- D