Test Plan Template Sample

Test plan

1.1 Purpose

We have to prescribe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.

1.2 Outline
A test plan shall have the following structure:
I. Test plan identifier
II. Introduction
III. Test items
IV. Features to be tested
V. Features not to be tested
VI. Approach
VII. Item pass/fail criteria
VIII. Suspension criteria and resumption requirements
IX. Test deliverables
X. Testing tasks
XI. Environmental needs
XII. Responsibilities
XIII. Staffing and training needs
XIV. Schedule
XV. Risks and contingencies
XVI. Approvals

The sections shall be ordered in the specified sequence. Additional sections may be included immediately prior to Approvals. If some or all of the content of a section is in another document, then a reference to that material may be listed in place of the corresponding content. The referenced material must be attached to the test plan or available to users of the plan.
Details on the content of each section are contained in the following sub classes.

1.2.1 Test plan Identifier
Specify the unique identifier assigned to this test plan.

1.2.2 Introduction
Summarize the software items and software features to be tested. The need for each item and its history may be included. References to the following documents, when they exist, are required in the highest level test plan:
a) Project authorization
b) Project plan
c) Quality assurance plan
d) Configuration management plan
e) Relevant policies
f) Relevant standards.

In multilevel test plans, each lower-level plan must reference the next higher-level plan.

1.2.3 Test items
Identify the test items including their version/revision level. Also specify traits of their transmittal media that impact hardware requirements or indicate the need for logical or physical transformations before testing can begin (e.g., programs must be transferred from tape to disk).
Supply references to the following test item documentation, if it exists:
a) Requirements specification
b) Design specification
c) Users guide
d) Operations guide
e) Installation guide
Reference any incident reports relating to the test items. Items that are to be specifically excluded from testing may be identified.

1.2.4 Features to be tested
Identify all software features and combinations of software features to be tested. Identify the test design specification associated with each feature and each combination of features.

1.2.5 Features not to be tested
Identify all features and significant combinations of features that will not be tested and the reasons.

1.2.6 Approach
Describe the overall approach to testing. For each major group of features or feature combinations, specify the approach that will ensure that these feature groups are adequately tested. Specify the major activities, techniques, and tools that are used to test the designated groups of features.
The approach should be described in sufficient detail to permit identification of the major testing tasks and estimation of the time required to do each one.
Specify the minimum degree of comprehensiveness desired. Identify the techniques that will be used to judge the comprehensiveness of the testing effort (e.g., determining which statements have been executed at least once). Specify any additional completion criteria (e.g., error frequency). The techniques to be used to trace requirements should be specified.
Identify significant constraints on testing such as test item availability, testing resource availability, and deadlines.

1.2.7 Item pass/fail criteria
Specify the criteria to be used to determine whether each test item has passed or failed testing.

1.2.8 Suspension criteria and resumption requirements
Specify the criteria used to suspend all or a portion of the testing activity on the test items associated with this plan. Specify the testing activities that must be repeated, when testing is resumed.

1.2.9 Test deliverables
Identify the deliverable documents. The following documents should be included:
a) Test plan
b) Test design specifications
c) Test case specifications
d) Test procedure specifications
e) Test item transmittal reports
f) Test logs
g) Test incident reports
h) Test summary reports.
Test input data and test output data should be identified as deliverables.
Test tools (e.g., module drivers and stubs) may also be included.

1.2.10 Testing tasks
Identify the set of tasks necessary to prepare for and perform testing. Identify all inter task dependencies and any special skills required.

1.2.11 Environmental needs
Specify both the necessary and desired properties of the test environment. This specification should contain the physical characteristics of the facilities including the hardware, the communications and system software, the mode of usage (e.g., stand-alone), and any other software or supplies needed to support the test.
Also specify the level of security that must be provided for the test facilities, system software, and proprietary components such as software, data, and hardware.
Identify special test tools needed. Identify any other testing needs (e.g., publications or office space). Identify the source for all needs that are not currently available to the test group.

1.2.12 Responsibilities
Identify the groups responsible for managing, designing, preparing, executing, witnessing, checking, and resolving. In addition, identify the groups responsible for providing the test items identified in 1.2.3 and the environmental needs identified in 1.2.11. These groups may include the developers, testers, operations staff, user representatives, technical support staff, data administration staff, and quality support staff.

1.2.13 Staffing and training needs
Specify test staffing needs by skill level. Identify training options for providing necessary skills.

1.2.14 Schedule
Include test milestones identified in the software project schedule as well as all item transmittal events. Define any additional test milestones needed. Estimate the time required to do each testing task. Specify the schedule for each testing task and test milestone. For each testing resource (i.e., facilities, tools, and staff), specify its periods of use.

1.2.15 Risks and contingencies
Identify the high-risk assumptions of the test plan. Specify contingency plans for each (e.g., delayed delivery of test items might require increased night shift scheduling to meet the delivery date).

1.2.16 Approvals
Specify the names and titles of all persons who must approve this plan. Provide space for the signatures and dates.

Regression Testing

Regression Testing is any type of software testing which seeks to uncover regression bugs. Regression bugs occur whenever software functionality that previously worked as desired stops working or no longer works in the same way that was previously planned. Typically regression bugs occur as an unintended consequence of program changes. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have reemerged. Experience has shown that as software is developed, this kind of reemergence of faults is quite common. Sometimes it occurs because a fix gets lost through poor revision control practices (or simple human error in revision control), but just as often a fix for a problem will be "fragile" - i.e. if some other change is made to the program, the fix no longer works. Finally, it has often been the case that when some feature is redesigned, the same mistakes will be made in the redesign that were made in the original implementation of the feature. Therefore, in most software development situations it is considered good practice that when a bug is located and fixed, a test that exposes the bug is recorded and regularly retested after subsequent changes to the program. Although this may be done through manual testing procedures using programming techniques, it is often done using automated testing tools. Such a 'test suite' contains software tools that allow the testing environment to execute all the regression test cases automatically; some projects even set up automated systems to automatically re-run all regression tests at specified intervals and report any regressions. Common strategies are to run such a system after every successful compile (for small projects), every night, or once a week.

Basic Terms Used in Software Testing...

Software Testing: A verification method that applies a controlled set of conditions and stimuli for the purpose of finding errors. This is the most desirable method of verifying the functional and performance requirements. Test results are documented proof that requirements were met and can be repeated. The resulting data can be reviewed by all concerned for confirmation of capabilities.

Bug / Defect / Error:
Software is said to have Bug if it features deviates from specifications.
Software is said to have Defect if it has unwanted side effects.
Software is said to have Error if it gives incorrect output.

Test Case: A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

Test Plan: A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the 'why' and 'how' of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.

Material Requirement Posts

Hi Friends,

In this post you can ask for material/document related to software testing. You can drop your request in this post ........

Carrier Realated Query Posts

Hi Friends,

In this forum you can ask your doubts and query related to Carrier in software testing. You can drop your query in this forum and Ill try to solve and reply you as soon as possible....

Query Related to Software Testing Posts

Hi Friends,

I am here to solve your doubts and query related to software testing. You can drop your query in this forum and Ill try to solve and reply you as soon as possible....