Files and Modules:
Include in this section any files, modules and code that must be distributed on the machine, and where they would be located. Also include registry settings, INI settings, setup procedures, de-installation procedures, special database and utility setups, and any other relevant data.

* Performance Monitoring Counters Setup And Configurations

Operational Issues
Is the program being monitored/maintained by an operational staff? Are there special problem escalation, or operational procedures for dealing with the feature/program/area?    

Backup

¨ Recovery

¨ Archiving

¨ Monitoring

¨ Operational Problem Escalation/Alert Methods

Scope of Test Cases
Statement regarding the degree and types of coverage the testing will involve. For example, will focus be placed on performance? How about client v.s. server issues? Is there a large class of testing coverage that will be intentionally overlooked or minimized? Will there be much unit and component testing? This is a big sweeping picture of the testing coverage - giving an overall statement of the testing scope.

Acceptance Criteria
How is “Good Enough To Ship” defined for the project? For the feature?
What are the necessary performance, stability and bug find/fix rates to determine that the product is ready to ship?
What are the top problems/issues that are recurring or remain open in this test plan? What problems remain unresolved?
Test Approach

Design Validation
Statements regarding coverage of the feature design - including both specification and development documents. Will testing review design? Is design an issue on this release? How much concern does testing have regarding design, etc. etc..

Data Validation
What types of data will require validation? What parts of the feature will use what types of data? What are the data types that test cases will address? Etc.

API Testing
What level of API testing will be performed? What is justification for taking this approach (only if none is being taken)?

Content Testing
Is your area/feature/product content based? What is the nature of the content? What strategies will be employed in your feature/area to address content related issues?

Low-Resource Testing
What resources does your feature use? Which are used most, and are most likely to cause problems? What tools/methods will be used in testing to cover low resource (memory, disk, etc.) issues?

Setup Testing
How is your feature affected by setup? What are the necessary requirements for a successful setup of your feature? What is the testing approach that will be employed to confirm valid setup of the feature?

Modes and Runtime Options
What are the different run time modes the program can be in? Are there views that can be turned off and on? Controls that toggle visibility states? Are there options a user can set which will affect the run of the program? List here the different run time states and options the program has available. It may be worthwhile to indicate here which ones demonstrate a need for more testing focus.

Interoperability
How will this product interact with other products? What level of knowledge does it need to have about other programs -- “good neighbor”, program cognizant, program interaction, and fundamental system changes? What methods will be used to verify these capabilities?

Integration Testing
Go through each area in the product and determine how it might interact with other aspects of the project. Start with the ones that are obviously connected, but try every area to some degree. There may be subtle connections you do not think about until you start using the features together. The test cases created with this approach may duplicate the modes and objects approaches, but there are some areas which do not fit in those categories and might be missed if you do not check each area.

Compatibility: Clients Is your feature a server based component that interacts with clients? Is there a standard protocol that many clients are expected to use? How many and which clients are expected to use your feature? How will you approach testing client compatibility? Is your server suited to handle ill-behaved clients? Are there subtleties in the interpretation of standard protocols that might cause incompatibilities? Are there non-standard, but widely practiced use of your protocols that might cause incompatibilities?

Compatibility:
Servers Is your feature a client based component that interacts with servers? Is there a standard protocol supported by many servers that your client speaks? How many different servers will your client program need to support? How will you approach testing server compatibility? Is your client suited to handle ill-behaved or non-standard servers? Are there subtleties in the interpretation of standard protocols that might cause incompatibilities? Are there non-standard, but widely practiced use of protocols that might cause incompatibilities?

Beta Testing
What is the beta schedule? What is the distribution scale of the beta? What are the entry criteria for beta? How is testing planning on utilizing the beta for feedback on this feature? What problems do you anticipate discovering in the beta? Who is coordinating the beta, and how?

Environment/System - General
Are there issues regarding the environment, system, or platform that should get special attention in the test plan? What are the run time modes and options in the environment that may cause difference in the feature? List the components of critical concern here. Are there platform or system specific compliance issues that must be maintained?

Configuration
Are there configuration issues regarding hardware and software in the environment that may get special attention in the test plan? Some of the classical issues are machine and bios types, printers, modems, video cards and drivers, special or popular TSR’s, memory managers, networks, etc. List those types of configurations that will need special attention.

User Interface
List the items in the feature that explicitly require a user interface. Is the user interface designed such that a user will be able to use the feature satisfactorily? Which part of the user interface is most likely to have bugs? How will the interface testing be approached?