EPLC_Master_Test_Plan_v . .doc

System Test Plan

Food and Drug Administration

<Project Name & Release Version #>

ENTERPRISE PERFORMANCE LIFECYCLE

SYSTEM TEST PLAN

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

[This document is a template of a System Test Plan 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 System Test Plan 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

51.0

PURPOSE AND SCOPE

51.1.

PURPOSE

51.2.

BACKGROUND

51.3.

SCOPE

62.0

GLOSSARY

63.0

RESOURCE REQUIREMENTS

63.1.

TESTING ENVIRONMENT

63.2.

OTHER TESTING COMPONENTS

63.3.

PERSONNEL

73.4.

STAFF TRAINING

74.0 Assumptions, constraints, and Risks

74.1.

TESTING ASSUMPTIONS

74.2.

TESTING CONSTRAINTS

74.3.

TESTING RISKS

75.0 Testing PROCESS

75.1.

METHODOLOGY

75.2.

TEST PROGRESSION / ORDER

75.3.

TEST MILESTONES

85.4.

TEST DATA

85.5.

RECORDING RESULTS

85.6.

ANALYZING RESULTS

85.7.

DEFECT AND BUG RESOLUTION

86.0 testing plan

96.1.

MODULE / FUNCTIONAL TESTING

106.2.

SYSTEM, PERFORMANCE, AND INTEGRATION TESTING

106.3.

SECURITY TESTING

106.4.

REGRESSION TESTING

126.5.

USER ACCEPTANCE TESTING

127.0 Test execution

127.1.

TEST IDENTIFICATION

127.2.

ENTRY CRITERIA

127.3.

COMPLETION CRITERIA

128.0 Progress Reporting

129.0

APPENDIX SUMMARY

14APPENDIX A: SYSTEM TEST PLAN APPROVAL

15APPENDIX B: REFERENCES

16APPENDIX C: KEY TERMS

17APPENDIX D: SYSTEM TEST SUMMARY REPORT

18APPENDIX E: BUG REPORT / DEFECT LOG

1.0 PURPOSE AND SCOPE

1.1. PURPOSE

[This section of the System Test Plan outlines what items, functions, and/or aspects of the system are being covered within this test plan. Identify the name of the system, the release or iteration number, the user organization, and location where the testing will be occurring. The test plan is created during the design phase of the development lifecycle and executed during the development phase.]

1.2. BACKGROUND

[This section of the System Test Plan provides a brief description of the history and other general information about to the system being developed.]

1.3. SCOPE

[This section of the System Test Plan describes the projected boundaries of the planned tests. Provide a brief description of what is going to be tested under this plan as well as what is going to be excluded. (All units, modules, level/extent of integration testing, user acceptance testing, etc.)]

[The following items will be tested under this test plan: (Refer to Requirements Traceability Matrix identification numbers if applicable)

· Item 1

· Item 2] [The following items will not be tested under this test plan: (Refer to Requirements Traceability Matrix identification if applicable)

· Item 1

· Item 2] [The following user features will be tested under this test plan: (Refer to Requirements Traceability Matrix identification if applicable)

· Function 1

· Function 2]

2.0 GLOSSARY

[This section of the System Test Plan provides 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. If terms and acronyms are listed in a separate document, reference that document’s name and location here.]

3.0 RESOURCE REQUIREMENTS

[This subsection of the System Test Plan identifies the equipment and personnel resources required to perform the testing identified within the scope of this document.]

3.1. TESTING ENVIRONMENT

[This subsection of the System Test Plan describes the testing environment needed to adequately test the components identified in this document. Include names, locations, availability and any specific configuration or version requirements of the identified equipment.]

3.2. OTHER TESTING COMPONENTS

[This subsection of the System Test Plan lists other components needed to support testing that are not part of the system being tested. This should include testing programs/devices and programming aids as well as which current systems must run in parallel with the new system to achieve functionality.]

3.3. PERSONNEL

[This subsection of the System Test Plan identifies the groups required to successfully perform the types of tests identified in Section 6.0 for this system. Include any special requirements, such as multiple-shift operation or key personnel.]

(Experience, Tool Sets, Etc.)

Responsibilities

Project Manager

Test Lead

Configuration Manager

Quality Team Member

Database Administrator

System Administrator

Enterprise Architect

Network Administrator

Security Representative

User Testers

3.4. STAFF TRAINING

[This subsection of the System Test Plan identifies the types of training and personnel to be trained. The Software Training plan can be referenced, if applicable.]

4.0 Assumptions, constraints, and Risks

4.1. TESTING ASSUMPTIONS

[This subsection of the System Test Plan identifies the assumptions that are being made regarding the system being tested. Suggestions of items to include would be equipment availability, resource skills, code availability, data availability, etc.]

4.2. TESTING CONSTRAINTS

[This subsection of the System Test Plan identifies the constraints that affect the testing. This could be availability of equipment, trained staff, crunched project schedule, etc.]

4.3. TESTING RISKS

[This subsection of the System Test Plan identifies the risks associated with the testing activities. Include a work around or mitigation plan for each of the identified risks. If the testing risks are listed within the Risk Management Database, provide the identification number of the applicable risks as well as the location of the database.]

5.0 Testing PROCESS

5.1. METHODOLOGY

[This subsection of the System Test Plan describes the general methodology or testing strategy for each type of testing described in this Test Plan.]

5.2. TEST PROGRESSION / ORDER

[This subsection of the System Test Plan describes the manner in which progression is made from one test to another, so the entire cycle is completed. Refer to the project schedule if applicable.]

5.3. TEST MILESTONES

[This subsection of the System Test Plan lists the testing milestones. Refer to the project schedule or WBS if applicable.]

[Some Key elements to consider in developing system test milestones are:

· Readiness of the system to be tested

· Readiness of the system test environment

· Readiness of the test team for a transition from final developmental testing to system testing

· Determination of system test execution completion criteria.]

5.4. TEST DATA

[This subsection of the System Test Plan specifies the test data to be used. It describes the source, volume, and frequency of the data. This section also describes the techniques that will be used for manipulating the test data into a form suitable for evaluation - such as manual or automated methods - to allow comparison of the results that should be produced to those that are produced.]

5.5. RECORDING RESULTS

[This subsection of the System Test Plan describes how the test results will be captured, recorded, stored, and communicated to all necessary parties, for both passed and failed tests. Identify what artifacts will need to be produced as a result of the testing activities. Some of these artifacts may include a testing matrix, test cases, defect log, incident/bug report, etc. (Refer to the Appendix section of this document for these templates) Also include the process/steps needed when the item fails the test.]

5.6. ANALYZING RESULTS

[This subsection of the System Test Plan describes how the test results will be analyzed / quantified. Include the pass/fail criteria and the number of times the various tests should be executed to ensure accurate results.]

5.7. DEFECT AND BUG RESOLUTION

[This subsection of the System Test Plan describes how the defects and bugs identified during the test execution steps will be recorded, reviewed, and resolved. Identify the criteria for defining the severity and priority (urgency) of the defects and bugs as it relates to the project deliverables. Also include a process for reviewing and resolving the defects and bugs. Include the frequency and attendees of the meetings. Refer to the Bug Report/Defect Log template in the Appendix as an example.]

6.0 testing plan

[This section of the System Test Plan describes the testing plans for development: integration, system security, and user acceptance phases.] [This subsection of the System Test Plan includes 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. Use the chart below to identify which tests will be performed as well as the intensity/level of effort/amount of time to be spent on each type.]

[In the “Testing Level” column enter how much testing needs to be done with each type of test listed. A High, Medium, Low or numerical scale (see table below) can be used designate the level of testing a particular test should receive.]

6.1. MODULE / FUNCTIONAL TESTING

[This subsection of the System Test Plan discusses the tests that examine integrated groupings of components. Module testing is performed after development has completed unit testing this is the first level of testing where formal problem reports are generated. This section will describe the levels of problem, severity and describe the resolution process (es). It will describe the disposition of test results (including the test data sets and outputs produced from the tests).]

6.2. SYSTEM, PERFORMANCE, AND INTEGRATION TESTING

[This subsection of the System Test Plan states how testing will determine system compliance with standards and satisfy the functional and technical requirements for that grouping of modules as well as the performance of the system as a whole. This subsection will describe the levels of problem severity and describe the resolution process (es). It will describe the disposition of test results (including the test data sets and outputs produced from the tests).]

6.3. SECURITY TESTING

[This subsection of the System Test Plan refers to the System Testing and Evaluation (ST&E) that is required to be performed by the system security plan.]

6.4. REGRESSION TESTING

[This subsection of the System Test Plan describes the Regression Testing. When retesting is required regression testing will be executed to verify that modifications have not caused unintended adverse side effects, while also ensuring new features or fixes to previously reported defects are successful. Describe the analysis process used to determine the regression tests. Describe the maintenance process of the regression test suite. Be aware that regression testing will increase the “typical” retest test case volume and test result analysis time.]

6.5. USER ACCEPTANCE TESTING

[This subsection of the System Test Plan describes how the user acceptance tests will be performed in a non-production environment that mirrors the environment in which the system will be fielded. Include a reference to the documentation that will be generated for the participants of the User Acceptance Test to ensure all aspects of the system are adequate and how their results are reported to the development or testing team.]

7.0 Test execution

7.1. TEST IDENTIFICATION

[Identify the test cases, scripts or scenarios that will be used to test each of the above listed items. If applicable, refer to the System Test Plan Report summary or the RTM for this information.]

7.2. ENTRY CRITERIA

[This subsection is used to assess the readiness of the system, the test environment, and the test team for a transition from final developmental testing to system testing. Identify what items need to be in place to start each type of test.]

7.3. COMPLETION CRITERIA

[This subsection is used to determine the test execution completion criteria. Basically, what set of criteria/metrics/statistics is used to determine when one type of testing is successful and testing can proceed onto the next step.]

8.0 Progress Reporting

[Describe and outline communication and reporting aspects of the testing cycle. Include the types of reports that need to be produced, the audience for each type of report, and the frequency of the reports. Identify any key deliverable or reporting dates as necessary.]

9.0 APPENDIX SUMMARY

[The templates contained within the appendix include samples for the System Test Summary Report (Appendix D) and Bug Report / Defect Log (Appendix E).]

APPENDIX A: SYSTEM TEST PLAN APPROVAL

The undersigned acknowledge that they have reviewed the <Project Name> System Test Plan and agree with the information presented within this document. Changes to this System Test Plan 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.

APPENDIX D: SYSTEM TEST SUMMARY REPORT

Project Name

Test Manager/Lead

Reference Number

Pass/Fail

APPENDIX E: BUG REPORT / DEFECT LOG

Project Name

Severity

Priority

Test Lead

Tester Completing Form

Bug 1

Bug 2

Bug 3

� Reference Number is used to quickly identify when a particular test will be executed within the testing cycle. It is suggested that a decimal system be used as outlined in the table below:

Position� Explanation� X.� Identifies which group the tests will be run. 1= First test group (Unit/ Functional tests); 2= 2nd test group (Initial Integration); 3= 3rd test group (Additional Integration); 4= Regression or Negative Testing; etc. �

x. X� The order the test case/ script/ scenario will be executed within the overall test group.� x.x.X� Indicates the “run number”, how many time this test has been or will be executed�

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