[See the last page for template assistance.]

Master Plan for Testing and Evaluation

<Project/Sub-project Title>

UCONN

Prepared for

University Information Technology Services

Babbidge Library, Storrs CT

369 Fairfield Rd, Unit 2209

Storrs, CT 06269-2209

File Name: Master Plan for Testing and Evaluation

Table of Contents

1.	Introduction	3

1.1	Overview	3

1.2	Purpose	3

2.	Background	4

3.	Scope	4

4.	Glossary	4

5.	Limitations and Traceability	4

5.1	Limitations	4

5.2	Traceability (Functional Requirements Traceability Matrix)	4

6.	Test Plans	5

6.1	Test Levels	5

6.1.1	Subsystem Integration Test	5

6.1.2	Unit Test	5

6.1.3	User Acceptance Test	6

6.1.4	Security Test	6

6.1.5	Load Test	6

6.1.6	Operational Readiness Test	7

6.1.7	Beta Test	7

6.2	Test Environment and Schedules	8

6.3	Unit Test	8

6.4	User Acceptance Test	8

6.5	Security Test	8

6.6	Load Test	9

6.7	Operational Readiness Test	9

6.8	Beta Test	9

6.9	Software Description	9

6.10	Milestones	9

6.11	Organizations and Locations	10

6.12	Schedule	10

6.13	Resource Requirements	10

6.14	Testing Material	10

6.14.1	Test Training	10

6.15	Test Methods, Evaluation and Deliverables	11

7.	Implementation signoff	12

<Project/Sub-project Title> Master Plan for Testing and Evaluation

Introduction

Overview

The Test Plan identifies the tasks and activities needed to be performed so that all aspects of the system are adequately tested and that the system can be successfully implemented. The Test Plan documents the scope, content, methodology, sequence, management of, and responsibilities for test activities. The Test Plan describes the test activities of the subsystem Integration Test, System Test, User Acceptance Test, and Security Test in progressively higher levels of detail as the system is developed.

The Test Plan provides guidance for the management of test activities, including organization, relationships, and responsibilities. The test case procedures may be included in the Test Plan or in a separate document, depending on system size. The business client assists in developing the Test Plan, which describes the nature and extent of tests deemed necessary. This provides a basis for verification of test results and validation of the system. The validation process ensures that the system conforms to the functional requirements in the FRD and that other applications or subsystems are not adversely affected. A test analysis report is developed at each level of testing to record the results of testing and certify readiness for system implementation (see the Integration and Test Phase).

Problems, deficiencies, modifications, and refinements identified during testing or implementation should be tracked under configuration control and tested using the same test procedures as those described in the Test Plan. Specific tests may need to be added to the plan at that time, and other documentation may need updating upon implementation. Notification of implemented changes to the initiator of the change request/problem report and to the users of the system is also handled as part of the configuration control process.

Purpose

The purpose of the Test Plan for the <Project/Sub-project Title> is to:

Provide a central artifact to govern the strategic approach of the test effort; it defines the general approach to be employed when testing the software and when evaluating the results of that testing. Planning artifacts will refer to the test strategy regarding the governing of detailed testing work.

Provide visible confirmation to test-effort stakeholders that adequate consideration has been given to the governing the test effort and, where appropriate, to have those stakeholders approve the strategy.

This Master Test Plan also supports the following specific objectives:

Identifies items that should be targeted by the tests.

Identifies the motivation for and ideas behind the test areas to be covered.

Outlines the testing approach that will be used.

Identifies the required resources and provides an estimate of the test efforts.

Lists the deliverable elements of the test project.

Background

[Provide a brief description of the background surrounding the project with specific reference or focus on important implications for the test effort. Include information such as the key problem being solved, the major benefits of the solution, the planned architecture of the solution, and a brief history of the project. Note that where this information is defined sufficiently in other documents, you might simply include a reference to those other documents if appropriate; however, it may save readers of this document time and effort if a limited amount of information is duplicated here: so you should use your judgment. As a general rule, this section should only be about three to five paragraphs in length.]

Scope

This Test Plan will cover the following testing activities as identified in the testing strategy:

[Include the sections below that will be in scope for testing your specific project. Unit Test, and User Acceptance will be required.]

Unit Test

User Acceptance Test

Load Test (recommended but optional)

Operational Readiness Test (recommended but optional)

Beta Test (recommended but optional)

Glossary

[Provide a list of all terms and abbreviations used in this document. If the list is several pages in length, it may be placed as an appendix.]

Limitations and Traceability

[Elaborate on the limitations summarized in Section 3, Scope, and cross-references the functional requirements and detailed specifications to the tests that demonstrate or partially demonstrate that capability.]

Limitations

[Describe limitations imposed on the testing, whether they are because of a lack of specialized test equipment, or constraints on time or resources. Indicate what steps, if any, are being taken to reduce program risk because of the test limitations(s).]

Traceability (Functional Requirements Traceability Matrix)

[Expand the traceability matrix created in the FRD by including test activities that address user requirements. The matrix begins with the user requirements and assists in tracing how the requirements are addressed in subsequent phases and documents, including the System Design Document and Test Plan, the matrix may be broken up into segments, if appropriate. For example, a separate matrix of test plan sections that reference particular sections in the system design document in the Design phase may be provided. The intent is to show that the test plan covers all functionality, performance, and other requirements associated with each design element (unit, module, subsystem, and system) in the system design document.

When a test supports a particular requirement, the relationship should be noted at their intersection in the matrix. The listed requirements may be explicitly stated or may be derived or implicit. All explicit requirements must be included. The granularity of the list should be detailed enough that each requirement is simple and testable.]

Test Plans

The items below identify the test itemssoftware, hardware, and supporting product elementsthat have been identified and excluded as targets for testing. This represents what items will and will not be tested.

[Provide an overview narrative describing the purpose and scope of the test for each testing phase and a list of the major target test items.

The item list should include items produced directly by the project development team and items that those products rely on; for example, basic processor hardware, peripheral devices, operating systems, third-party products or components, etc. This may simply be a list of the categories or target areas. If a specific item will not be tested, indicate the justification, such as:

“These tests do not help achieve the evaluation mission.”

“There are insufficient resources to conduct these tests.”

“These tests are unnecessary due to the testing conducted by UITS.”

Include the sections below that will be in scope for testing your specific project. Unit Test, and User Acceptance will be required.]

Test Levels

[Include a list of the types of software testing to be performed. List all applicable levels and enter “Not applicable” if a particular level of testing does not apply to the project.]

Subsystem Integration Test

[Discuss the tests that examine the subsystems make up of integrated groupings of software units and modules. This is the first level of testing where problem reports are generated; these reports are classified by severity, and their resolution is monitored and reported. Subsystem integration test results (including the test data sets and outputs produced from the tests) may be delivered as part of the final Test Plan, with the integration test analysis report or as an appendix.]

Unit Test

[Describe the type of testing that determines unit level compliance with standards and satisfaction of functional and technical requirements when executed on target hardware using simulated operational data files and prepared test data. All findings are recorded in a unit test analysis report.]

Overview

[Provide overview narrative here.]

Unit Test Items Tested

[List unit test items here.]

Unit Test Items Not Tested

[List unit test items not tested here.]

User Acceptance Test

[Describe the tests performed in a non-production environment that mirrors the production environment. Every system feature may be tested for correctness and satisfaction of functional requirements. System interoperability, all documentation, system reliability, and the level to which the system meets user requirements are evaluated. Performance tests may be executed to ensure that screen response time, program run time, operator intervention requirements, and reconciliation issues are addressed.]

User Acceptance Test Plan Entry Criteria

The criteria that determine when user acceptance testing can begin include the following:

No critical or major severity issues remaining from unit testing

Completed User Acceptance Test Scripts

Correct version of software is moved into the user acceptance testing environment

User Acceptance Test Plan Exit Criteria

The criteria that determine when the user acceptance testing is complete, or that continued execution provides no further benefit, include the following:

Successful execution of User Acceptance Test Scripts

No open critical, major or average severity issues unless the issue is determined to be low impact, low risk. To be reviewed with Project Manager, Test Manager and Software Architect for acceptable resolution.

Suspension and Resumption Criteria

When a defect is detected during User Acceptance Testing, testing should halt and the tester should log the defect in a Change Request form. The tester should then give the form the Test Analyst for review and determination of error and severity. If the defect is not critical or major severity then testing may continue.

To resume a suspended test, the defects must be corrected and the software promoted to the testing environment. This shall be reflected on the change request form. Initialization steps may be required to resume the test script depending on where the defect occurred.

Security Test

[Describe the tests performed to determine if the system meets all of the security requirements listed in the FRD. Include internal controls or application security features mentioned in the context of security testing. Security testing is performed in the operational (production) environment under the guidance of the security staff.]

Load Test

Load Test Entry Criteria

The criteria that determine when load testing can begin include the following:

No critical or major severity issues remaining from unit testing

Completed Integration Test Scripts

Correct version of software is moved into the load testing environment

Load Test Plan Exit Criteria

The criteria that determine when the load testing is complete, or that continued execution provides no further benefit, include the following:

Successful execution of Load Test Scripts

No open critical, major or average severity issues unless the issue is determined to be low impact, low risk. To be reviewed with Project Manager, Test Manager and Software Architect for acceptable resolution.

Suspension and Resumption Criteria

When a defect is detected during Load Testing, testing should halt and the tester should log the defect in a Change Request form. The tester should then give the form the Test Analyst for review and determination of error and severity. If the defect is not critical or major severity then testing may continue.

To resume a suspended test, the defects must be corrected and the software promoted to the testing environment. This shall be reflected on the change request form. Initialization steps may be required to resume the test script depending on where the defect occurred.

Operational Readiness Test

Operational Readiness Test Entry Criteria

The criteria that determine when operational readiness testing can begin include the following:

No critical or major severity issues remaining from any testing

Completed Operational Readiness Test Scripts

Correct version of software is moved into the production environment

Operational Readiness Test Plan Exit Criteria

The criteria that determine when the operational readiness testing is complete, or that continued execution provides no further benefit, include the following:

Successful execution of Operational Readiness Test Scripts

No open critical, major or average severity issues unless the issue is determined to be low impact, low risk. To be reviewed with Project Manager, Test Manager and Software Architect for acceptable resolution.

Suspension and Resumption Criteria

When a defect is detected during Operational Readiness Testing, testing should halt and the tester should log the defect in a Change Request form. The tester should then give the form the Test Analyst for review and determination of error and severity. If the defect is not critical or major severity then testing may continue.

To resume a suspended test, the defects must be corrected and the software promoted to the testing environment. This shall be reflected on the change request form. Initialization steps may be required to resume the test script depending on where the defect occurred.

Beta Test

Beta Test Entry Criteria

The criteria that determine when beta testing can begin include the following:

[Specify the criteria that will be used to determine where the execution of beta testing can begin]

Beta Test Plan Exit Criteria

The criteria that determine when the beta testing is complete, or that continued execution provides no further benefit, include the following:

[Specify the criteria that will be used to determine where the execution of beta testing is complete or that continued testing provides no further benefit.]

Suspension and Resumption Criteria

[Specify the criteria that will be used to determine whether testing should be prematurely suspended or ended before the plan has been completely executed, and under what criteria testing can be resumed.]

Test Environment and Schedules

[Provide a brief description of the inputs, outputs, and functions of the software being tested. Include the sections below that will be in scope for testing your specific project. Unit Test, Integration Test, and User Acceptance will be required. Customize as necessary.]

Unit Test

Workstations	Application Server	Mainframe	Mail Server	Database Server
Name
Software
Physical Location
IP Address
URL/Database

User Acceptance Test

Workstations	Application Server	Mainframe	Mail Server	Database Server
Name
Software
Physical Location
IP Address
URL/Database

Security Test

Workstations	Application Server	Mainframe	Mail Server	Database Server
Name
Software
Physical Location
IP Address
URL/Database

Load Test

Workstations	Application Server	Mainframe	Mail Server	Database Server
Name
Software
Physical Location
IP Address
URL/Database

Operational Readiness Test

Workstations	Application Server	Mainframe	Mail Server	Database Server
Name
Software
Physical Location
IP Address
URL/Database

Beta Test

Workstations	Application Server	Mainframe	Mail Server	Database Server
Name
Software
Physical Location
IP Address
URL/Database

Software Description

[List the software being tested. Provide a description of the purpose of the software being tested, and any interfaces to subsystems or other components of the system.]

Milestones

[List the milestone events and dates for the testing. Identify the key schedule milestones that set the context for the testing effort. Avoid repeating too much detail that is documented elsewhere in plans that address the entire project.]

Table 2: Milestones

Milestone	Planned Start Date	Planned End Date	Estimated Effort

Organizations and Locations

[Provide information on the participating organizations and the location where the software will be tested.]

Schedule

[Show the detailed schedule of dates and events for the testing by location. Events should include familiarization, training, test data set generation, and collections, as well as the volume and frequency of the input for testing.]

Resource Requirements

[Define the resource requirements for the testing.]

Equipment

[Show the expected period of use, types, and quantities of equipment needed.]

Software

[List other software needed to support testing that is not part of the software being tested. This should include debugging software and programming aids as well as many current programs to be run in parallel with the new software to ensure accuracy; any drivers or system software to be used in conjunction with the new software to ensure compatibility and integration; and any software required to operate the equipment and record test results.]

Personal

[List the number of, skill types of, and schedules for personnel - from the user, database, Quality Assurance, security, and development groups - who will be involved in the test. Include any special requirements, such as multiple-shift operation or key personnel.]

Testing Material

[Describe the documents needed to perform the tests. It could include software, resources, data and other information.]

Test Training

[Describe or reference the plan for providing training in the use of the software being tested. Specify the types of training, personnel to be trained, and the training staff.]

Test Methods, Evaluation and Deliverables

[Document the test methodologies, conditions, test progression or sequencing, data recording, constraints, criteria, and data reduction.]

Methodology

[Describe the general methodology or testing strategy for each type of testing described in this Test Plan.]

Conditions

[Specify the type of input to be used, such as real-time entered test data or canned data for batch runs. Describe the volume and frequency of the input, such as the number of transactions per second tested, etc. Sufficient volumes of test transactions should be used to simulate live stress testing and to incorporate a wide range of valid and invalid conditions. Data values used should simulate live data and also test limited conditions.]

Test Progression

[Describe the manner in which progression is made from one test to another, so the entire cycle is completed.]

Data Recording

[Describe the method used for recording test results and other information about the testing.]

Constraints

[Indicate anticipated limitations on the test because of test conditions, such as interfaces, equipment, personnel, and databases.]

Criteria

[Describe the rules to be used to evaluate test results, such as range of data values used, combinations of input types used, or maximum number or allowable interrupts or halts.]

Data Reduction

[Describe the techniques that will be used for manipulating the test data into a form suitable for evaluation such as manual or automated methods that allow comparison of the results that should be produced to those that are produced.]

Testing and Evaluation signoff

The terms and conditions of the Functional Requirements Document apply in full to the services and products provided under the Implementation Plan.

[Client name]	[Services provider name]
Full name	Full name
Title	Title
Signature	Signature
Date	Date

Revision History

Version	Date	Summary of Changes	Author	Revision Marks (Yes/No)
0.1	Initial revision.

[Note: This template is provided to assist authors with the UITS SDLC.

Blue or black text within arrow brackets (< >) should be customized before publishing this document. Be sure to change the color of the text to black before publishing this document.

Blue text within square brackets ([ ]) provides instructions and guidance and should be deleted before publishing this document.

This document uses automatic fields:

Viewing Automatic Fields
If you cannot see the automatic fields in this document, select Tools>Options, and then choose the View tab; in the Field Shading drop-down list, choose Always.

Customizing Automatic Fields
To customize the automatic fields in this document, select File>Properties and then replace the information in brackets (< >) with the appropriate information for this document; be sure to also customize the Custom properties by choosing the Custom tab, selecting a property, changing its value, and then clicking Modify. Repeat this for each custom field. Click OK to close the dialog.

Updating Automatic Fields
You can update the automatic fields with new, customized information by selecting Edit>Select All (or Ctrl+A) and then pressing F9, or by simply clicking on a field and pressing F9. This must be done separately for Headers and Footers (View>Header and Footer, Ctrl+A, F9). See MS Word help for more information on working with fields.]