Studio:Test Plan Template

This is a template outline for a VaS test plan.

Introduction

<
State the purpose of the Test Plan (this is essentially the executive summary). Provide a brief summary of the software under test. Outline the major functions and features at a high level.
>

Goals

<
Outline the goals specified by the customer for testing
>

Scope

<
Define the scope of the test plan. From the major functions and features outlined above, describe what will and will not be covered
>

Test Strategy

<
Define the test coverage goals for the project. Describe the method(s) that will be used to measure the coverage obtained.
>

Components/Interfaces to be Tested

<
Provide a detailed list of the items to be tested. The list may include modules, units, classes and/or functions. This information should include version numbers, configuration requirements, or feature flags when applicable (especially if multiple versions are to be covered).

If tests are to be interface based then all the interfaces to be verified should be listed. If test are to be functionality based then all the desired functionalities should be listed.
>

Components/Interfaces not to be Tested

<
Provide a detailed list of the interfaces, features (flags) or functionality which is NOT to be tested.
>

Test Environments and Configuration

<
Describe the architecture of the test framework to be used in implementing the test strategy. Use block diagrams an other aids where appropriate.

Special Requirements

Describe any special requirements needed for the testing to be performed.

This includes:

• Target hardware and software
• Test frameworks and agents
• Test harnesses and fixtures
• Test equipment
• Third party software applications and tools
• Staffing and skills training

>

Integration with Customer Target Build

<
If testing is to be done on-target, how will the STRIDE runtime be integrated with target code? How will IMs be generated and integrated with the target code? How will IMs be kept in sync with the target code?
>

Report Generation

<
Provide link to web based reporting. Describe suites being used for publishing.
>

Project Tracking

<
Describe the measures that will be used to track progress and measure results (test case counts, reports, coverage metrics, etc). Tie these back to the customer goals if possible.
>

Bug Tracking

<
Describe how test failures will be reported as bugs to the customer. Who is responsible for entering issues into the customer's bug tracking system? Who is responsible for assisting customer in taking issues to resolution?
>

References

<
List all customer accessible documentation that supports this test plan. From each item listed, it should be possible to locate the document. Refer to the actual version / release number if stored in the customer’s configuration management system. Use hyper-links if referencing on-line documentation.

Documents that may be referenced include:

• Software Requirements Specifications
• Other Test Plans & Specifications
• Detailed Design Documents
• Interface Control Documents (ICD)
• Standards & Conventions Guidelines
• Process & Methodology Documents
• Programmer & User Guides
• Source Code

>