A test plan is generally a document that
provides and records important information about a test project, such as
background information that is relevant or resources that will be used during a
testing effort. Also included in such plans is entrance, stopping, and exit
criteria. These are all very important for running an accountable test effort.
Besides all of this, other material needs to be included as well such as
statements of quality risks, Tests to be performed, assumptions, dependencies,
and risks, as well as a basic schedule
Timeline that indicates what testing is
being done, when it will start, when it will end and any milestones that might
be pertinent. It should give complete information like ‘why’ and ‘how’ product
is validated. Now we will look in detail about the contents of a test plan.
(Note) If the organization has the CMM certification it might have a standard
template, if you are suppose to prepare a test plan you can request for that
Template.
Types of Test Plans: -
a) Unit test plan
b) Integration
test plan
c) System test
plan
d) Acceptance test
plan
Contents of a test plan: -
Introduction: -
This is the first section of the test plan
and should contain information about what are the things/information we are
presenting in this (test plan) document. In short we can say a brief
description/purpose about the test execution plan of that specific Project.
Approach:-
This section of the test plan will describe
what type of test approach we are adopting for execution of the project. Is it
manual testing or automation testing? With suitable reasons.
Schedules: -
Here mention the details of the project
schedules , such as start date and end date .In between if we have beta or
alpha release mention schedule(s) of that also, apart from these, give build
wise start date and end dates. If test cases are divided into module Wise you
can give the schedules as per that also.
(Note) It is advised to include buffer time in
the schedules, so that unexpected events can be handled in time.
Resources: -
Give the Hardware, software(s) requirements
and the man power needed for the Project execution.
(Note1) Retain spare systems (systems apart from
the test environment) and at least one backup person, so that unexpected events
can be handled
(Note2) Do consider the budget allocation for that
project, while requesting for the hardware & software(s) and manpower.
Environment: -
Give a detailed list of environment(s) on
which the test bed setup has to be created. Mention each OS & software(s)
along with its version(s) and patch(s).
(Note)Any specific test cases those are specific
to OS or software(s). Give the total number of such specific test cases in a
tabular format (if applicable)
Test methodologies: -
This section of the test plan mentions the
details of the type of test methodology that is used to validate the
system/application /product. Give a brief description about the Methodology
adopted Along with the suitable reasons why we have chosen method with respect
to the project/product. Following are most frequently used test methodologies
a) Black box testing methodology
b) Gray box testing methodology
c) White Box testing methodology
Requirements/features to be tested: -
List out the features/requirements of the
system/product/application that are to be tested. Give a detailed list module
wise. (If available).
(Note) Represent the data in a tabular format with use case id, SRS id and
test cases id
This makes an easy readability.
Requirements/features not to be tested: -
List out the features/requirements of the
System/product/application that are not to be tested because of various reasons
like
a) Non availability of environment or
different software(s).
b) Any specific feature(s) or functionality
that is not yet implemented in the
Current Build ETC.
9) Assumptions: -
List out the possible assumptions for the
project like
a) It is assumed
that test environment is properly configured and specific to that
Project only which will not be used for any
other purpose
b) Development's
test environment will be separate from QA's test environment
d) Development
team releases testable software to testing team on schedule ETC
10) Risks: -
Here mention the possible risks for the project
execution. They might be
For example
a) Testing the functionality of the product
which is integrated with a third Party software
b) Team is not properly trained on the
technology on which the application
Is built and to be tested
c) Execution of many test cases in a
shorter period of time due to dead lines ETC
11) Test Exit Criteria: -
Give the
information about when to stop testing of a product. List out the conditions at
which testing can be stopped. The reasons can be like
a) All test cases are executed and bugs
were fixed to an extent
b) Test cases completed with certain
percentage passed
c) Project has reached the end date
d) Product is stable after certain
regression test cycles performed on it.
e) Bug rate falls below a certain level ETC
12) Release Criteria: -
When testing is completed and QA deems that
the following Items have been satisfactorily met, a recommendation will be made
by QA to release the product. A Test and Evaluation report will be submitted
reflecting quality Assurance assessment of the product at this time.
a) All Severity 1
defects are resolved.
b) All must be
fixed bugs or high priority bugs are resolved
c) All Severity 2
problems must have acceptable work-arounds, which are documented in
Release
Notes or Read me file, which are available to customers.
d) The main
features of the product are fully implemented and function according to
Requirements.
e) All test cases
are executed at least once
f) Product is
stable on specified OS
g) User
documentation is accurate and fully descriptive of the product. ETC
(This is the end of the contents of the
test plan)
