EPLC_Unit_Test_Report_r . _v . .doc

<Project Name> Project Management Plan

Version: 1.0 Error! Unknown document property name.

Food and Drug Administration

<Project Name & Release Version #> Software Unit Test Report OIM / IT Governance

Enterprise Performance Life Cycle Document Version Number: <1.0> Document Version Date: <mm/dd/yyyy> Notes to the Author

[This document is a template of a Software Unit Test Report document for a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.

· Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.

· Blue italicized text enclosed in angle brackets (<text>) indicates a field that should be replaced with information specific to a particular project.

· Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.

When using this template, the following steps are recommended:

1. Replace all text enclosed in angle brackets (e.g., <Project Name>) with the correct field document values. These angle brackets appear in both the body of the document and in headers and footers. To customize fields in Microsoft Word (which display a gray background when selected) select File->Properties->Summary and fill in the appropriate fields within the Summary and Custom tabs.

After clicking OK to close the dialog box, update all fields throughout the document selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update each field individually by clicking on it and pressing F9.

These actions must be done separately for any fields contained with the document’s Header and Footer.

2. Modify boilerplate text as appropriate for the specific project.

3. To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.

4. To update the Table of Contents, right-click on it and select “Update field” and choose the option - “Update entire table”.

5. Before submission of the first draft of this document, delete this instruction section “Notes to the Author” and all instructions to the author throughout the entire document.

VERSION HISTORY

[Provide information on how the development and distribution of the Software Unit Test Report will be controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.]

Version Number Implemented

By Revision

Date Approved

By Approval

Date Description of Change

TABLE OF CONTENTS

Introduction

51.1 Purpose of Software Unit Test Report

51.2 Scope

51.3 System Overview

51.4 Project References

61.5 Acronyms and Abbreviations

61.6 Points of Contact

61.6.1 Information

61.6.2 Coordination

Test Definition

62.x [Test Identifier and Type]

72.x.1 Requirements to be Tested

72.x.2 Expected Results

72.x.3 Test Hierarchy

72.x.4 Extent of Test

72.x.5 Test Data

82.x.6 Input Commands

82.x.7 Output Notification

92.x.8 Support Software

92.x.9 Error Handling

92.x.10 Test Conditions

92.x.11 Extent of Test

92.x.12 Test Constraints

Test Execution

93.1 Test Schedule

93.2 Test Progression

93.3 Test Criteria

103.3.1 Tolerance

103.3.2 Samples

103.3.3 System Breaks

103.4 Test Control

Test Results

104.1 Unit Testing

11APPENDIX A: Project Management Plan Approval

12APPENDIX B: REFERENCES

13APPENDIX C: KEY TERMS

1 Introduction

1.1 Purpose of Software Unit Test Report

[Provide the purpose of the Software Unit Test Report]

1.2 Scope

[Describe the scope of the Test Plan as it relates to the project.]

1.3 System Overview

[Provide a brief system overview description as a point of reference for the remainder of the document. In addition, include the following:

· Responsible organization

· System name or title

· System code

· System category

· Major application: performs clearly defined functions for which there is a readily identifiable security consideration and need

· General support system: provides general ADP or network support for a variety of users and applications

· Operational status

· Operational

· Under development

· Undergoing a major modification

· System environment and special conditions]

1.4 Project References

[Provide a list of the references that were used in preparation of this document. Examples of references are:

· Previously developed documents relating to the project

· Documentation concerning related projects

· HUD standard procedures documents]

1.5 Acronyms and Abbreviations

[Provide a list of the acronyms and abbreviations used in this document and the meaning of each.]

1.6 Points of Contact

1.6.1 Information

[Provide a list of the points of organizational contact (POCs) that may be needed by the document user for informational and troubleshooting purposes. Include type of contact, contact name, department, telephone number, and e-mail address (if applicable). Points of contact may include, but are not limited to, helpdesk POC, development/maintenance POC, and operations POC.]

1.6.2 Coordination

[Provide a list of organizations that require coordination between the project and its specific support function (e.g., installation coordination, security, etc.). Include a schedule for coordination activities.] 2 Test Definition

2.x [Test Identifier and Type]

[This section provides a description of the unique name or descriptor of the test and describes the type of test and objective. Each test should be under a separate section header, 2.0 - 2.x.] [Test types may include the following:

· Requirements Validation

· Functional Testing

· Performance/Volume/Stress Testing

· Security Testing

· Ease of Use

· Operational Testing

· Documentation Testing

· Procedure Testing

· Interface Testing

Refer to the Section 5.1 of the System Development Methodology (SDM) for a complete description of each of these test types.] 2.x.1 Requirements to be Tested

[Describe the system and program requirements that will be tested with this particular test.] 2.x.2 Expected Results

[Describe the expected results of the testing performed.] 2.x.3 Test Hierarchy

[Describe the location of the test in the hierarchy of the testing to be performed.] 2.x.4 Extent of Test

[Identify the software units and programs that are to be included in the test. Identify the program functions and interfaces that will be tested.]

2.x.5 Test Data

[Identify the test data required for the particular test, and describe to the data field level.] 2.x.5.1 Test Data Reduction

[The available techniques may include:

· Manual collection and collation of system test output into test sequence order, followed by verification of the results

· Semiautomatic inspection of test results as obtained by data recording means using a test data reduction program, followed by manual inspection of selected test results that do not lend themselves to complete reduction by automatic means

· Automatic inspection of test results specifically recorded for manipulation by the test data reduction program

Test results as recorded include all items of test significance. The test data reduction program contains an image of correct data output for an item-by-item comparison of data, and provides a summary of an evaluated test as output. Describe the technique to be used for manipulation of the raw test data into a form suitable for evaluation, if applicable.] 2.x.5.2 Input Test Data Control

[Describe the manner in which input data are controlled to test the system with a minimum number of data types and values; exercise the system with a range of bona fide data types and values that test for overload, saturation, and other “worst case” effects; and test the system with bogus data and values that test for rejection of irregular input.] 2.x.5.3 Output Test Data Control

[Identify the media and location of data produced by the test. Describe the manner in which output data are analyzed to detect whether an output is produced; evaluate output as a basis for continuation of the test sequence; and evaluate the test output against the required output to assess system performance.] 2.x.5.4 Data Recovery

[Describe how original data will be recovered before and after test execution.] 2.x.5.5 Test Data Handling

[Describe how test data will be identified, maintained, and version-controlled.] 2.x.6 Input Commands

[Describe the manner in which input commands are used to control initialization of the test, to halt or interrupt the test, to repeat unsuccessful or incomplete tests, to alternate modes of operation as required by the test, and to terminate the test. Describe job control language to be executed, if applicable.] 2.x.7 Output Notification

[Describe the manner in which output notifications (messages output by the system concerning status or limitations on internal performance) are controlled in order to:

· Indicate readiness for the test

· Provide indications of irregularities in input test data or test database because of normal or erroneous test procedures

· Present indications of irregularities in internal processing of test data because of normal or erroneous test procedures

· Provide indications on the control, status, and results of the test as available from any auxiliary test software] 2.x.8 Support Software

[Identify external or existing programs needed to support the test. Include version and release numbers if appropriate. Identify utilities or other data manipulation tools that will be used to create or modify test data, to create erroneous data, as well as “staged” data to test all system interfaces. ] 2.x.9 Error Handling

[Describe procedures for reporting errors, test results, and reworking/retesting programs.] 2.x.10 Test Conditions

[Indicate whether the test is to be performed using the normal input and database, or whether some special test input is to be used.] 2.x.11 Extent of Test

[Describe the extent of testing employed by this test. Where limited testing is to be used, the test requirements will be presented either as a percentage of a well-defined, total quantity or as a number of samples of discrete operating conditions or values. Identify all test drivers and stubs. Discuss the rationale for adopting limited testing.] 2.x.12 Test Constraints

[Describe any anticipated limitations imposed on the test because of system or test conditions (timing, interfaces, equipment, personnel).] 3 Test Execution

3.1 Test Schedule

[Provide a listing or graphic depicting the locations at which the test will be scheduled and the timeframes during which the test will be conducted. Identify the duration of the test at each site.]

3.2 Test Progression

[Include an explanation concerning the manner in which progression is made from one test to another so the cycle or activity for each test is completely performed.]

3.3 Test Criteria

[Describe the rules by which test results will be evaluated.]

3.3.1 Tolerance

[Discuss the range over which a data output value or system performance parameter can vary and still be considered acceptable.]

3.3.2 Samples

[Establish the minimum number of combinations or alternatives of input conditions and output conditions that can be exercised to constitute an acceptable test.]

3.3.3 System Breaks

[Discuss the maximum number of interrupts, halts, or other system breaks which may occur because of non-test conditions.]

3.4 Test Control

[Indicate whether the test is to be controlled by manual, semiautomatic, or automatic means.] 4 Test Results

4.1 TC "\"5.A. CMS Employees and Users of CMS IT Resources\"" \l 2 Unit Testing

The table below summarizes the results of unit testing:

<Yes> or <No>

[If the test case failed, list the corresponding Test Incident ID in the Comments column.]

APPENDIX A: Project Management Plan Approval

The undersigned acknowledge that they have reviewed the <Project Name> Software Unit Test Report and agree with the information presented within this document. Changes to this Software Unit Test Report will be coordinated with, and approved by, the undersigned, or their designated representatives.

Signature:

Date:

Print Name:

Title:

APPENDIX B: REFERENCES

[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.]

The following table summarizes the documents referenced in this document.

APPENDIX C: KEY TERMS

The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

Template Version 2.0 (Last Modified on Mar 27, 2009)

PAGE

Revision Date: Error! Unknown document property name.

EPLC_Project_Management_Plan_Template.doc