Test Plan for YourProject 

Date this plan was last saved:

Author: 

Note: Use the Test Planning checklist on the Project Management Portal to assist with completion of this plan.

1.    Testing Overview

1.1.   Purpose and Scope of the Plan

Provide a brief statement of what systems and test phases (e.g., integration, system, alpha, beta, all) are addressed in the test plan.  Reference the requirements which will be verified by this testing.

1.2.   To be  Tested

What functions (applications, subsystems, ...) will be verified during the execution of this test plan?

1.3.   Not to be Tested

What will be excluded from the testing? 

1.4.   Other Limitations or Assumptions

Are there things that can't be tested?  Are there test methods that can't be used?

2.    Product Changes

2.1.   New, Changed, Obsolete Items

List (or provide a link to) the specific deliverables to be tested.  Each deliverable should have an associated risk (if it fails in production), needed environmental components, and summary of the changes. This list would be used to determine test priorities, track test status, and to verify production readiness.

2.2.   Maintenance - Resolved Defects/Enhancements

List (or provide a link to) bugs or requests targeted to be fixed for this release, if any.

3.   Test Environment

3.1.    System Configuration

List the components that make up each test environment (e.g., integration, beta) on all platforms.  Include servers and other hardware, systems or other software, databases, MCP usercodes, etc. Keep in mind that the test environment should look as much like the production environment as possible, in order to provide the highest level of confidence in the verification of the changes. If the environments are too different, changes that appear to function well in test may fail in production. For example:

3.2.    Data Requirements

List the data needed for testing, e.g., a full copy of a production database from a given financial cycle. Include any specific test data requirements, such as certain transaction types.

3.3.    Utilities, tools, and software

List supporting tools such as simulators or comparison utilities needed for testing (e.g., Red Gate SQL Data Compare, ERGO).

4.    Strategy / Approach

4.1.    Dependencies, Risks and Risk Management

List any items or actions upon which the execution of the tests is dependent.  List any risks if tests are not executed or fail.  Refer to the risk assessment made of the deliverables in the Product Changes section of this plan.

4.2.    Test Approach

Outline how the test environment and deliverables under test will be handled.  Include how tests will be prioritized, types of tests (e.g., parallel), expected phases (e.g., unit, integration, system, alpha, beta, pilot).  Explain how requirements will be traced to tests and how the project team will know which requirements have had at least one associated test case executed (include a link to the requirements/testing (test coverage) traceability matrix.).  Include a strategy for identifying both positive tests (does it work?) and negative tests (it doesn't break).

4.3.    Software Configuration Management (Version Control) and Environment Migration

Describe how the test environment will be controlled, and how the changes will be stored and migrated from the development environment into the final test environment.  If tools are used, identify them (e.g., VSS, SURE).

4.4.    Problem Reporting and Test Tracking Procedures

Describe how tests will be tracked (executed, failed, associated defects) and the problem reporting procedures, including how problems will be prioritized.  If tools are used, identify them (e.g., RT, TestTrack).  For example:

Problem Reporting

• As problems are found during system and acceptance testing they will be recorded and tracked so that the list of problems found and the problem status (open, failed, resolved) can be provided to the project team.
• If a problem is found during testing in another system (e.g., ASTRA), it will be logged and reported to that system's owners. 

Test Tracking

• Team members will function as testers, running test cases, evaluating and recording test results, and generating problem reports.
• A test execution log (tests that have been run, passed, failed) will be kept to produce a test results summary. 
• If needed, supporting documentation (e.g., screen prints and reports) will be retained for highly critical test runs. 
  

4.5.    Acceptance Criteria

Identify the tasks, milestones or deliverables that must reach a given state in order for the testing phase(s) to be declared complete. 

For example:

• All high-priority defects have been corrected and any of the associated tests rerun successfully
• All outstanding (unresolved) defects have been documented and include workarounds where required
• Requirements coverage is 100% (100% of test cases addressing requirements have been executed) or discrepancies documented and acceptable
• Code coverage (the percentage of code tested) is at least 95%
• The success rate (test cases passed) is at least 95%; the failure rate is documented and acceptable
• Acceptor has signed off on test results and outstanding issues.

5.    Staff Requirements / Roles and Responsibilities

6.   Work Plan

Prepare a testing work plan with major testing milestones. Document specific functions to be tested either here or in separate test plan documents. Perform these activities in the sequence identified as much as possible. For example:

6.1.    Pre-test milestones

Identify the milestones to be completed prior to starting test execution.  For example:

1. Components to be tested identified
2. Risk assessment complete (new or changed components have been tagged as high, medium or low-risk, based on risk of failure in production)
3. High Level Test planning complete
4. Tests identified
5. Tests mapped to components
6. High priority Tests details documented
7. Test environment ready (Windows and Unisys)
8. Test data ready (e.g., DMS II databases populated, synthetic data created or defined)
9. Unit tests complete
10. Initial integration testing complete

6.2.    Test milestones

Identify the milestones to be completed during actual test execution.  For example:

1. Installation/Conversion tests
2. Basic Configuration Acceptance test
3. Regression tests
4. Functional tests (e.g., business logic scenarios, data handling tests)
5. Security tests
6. Report tests
7. User interface and usability tests
8. System interface tests
9. Performance tests
10. Volume and stress tests
11. Error recovery tests
12. Documentation/help verification
13. User acceptance tests (see User Acceptance Testing on the Software Testing site.)
14. Implementation verification tests
    

6.3.    Transition to Production milestones

Identify the milestones to be completed prior to or during transition to production. Suggested milestones:

1. Test results and issues summary review.
2. Deliverables accepted by users.
3. Checkpoint - decide whether to move into production.
4. Production deployment (may be in implementation plan)
5. Implementation verification complete (Basic Configuration Acceptance Test).

7.   Issues

Track issues here or provide a link to testing issues with their status.

8.   Tests

Describe the sets of tests to be run.  List the specific test cases here, or provide an overview plus a link to the document(s) describing the test cases.
Possible tests are listed in the Work Plan section. 

9. Test Results Summary

Include the results summary here or provide a link to the detailed and summary results.  For example: