Test plan for application

A brief summary of the application or product being tested. Outline all of the features at a high level.

The specific objectives that testing must achieve for the application or product. Objectives must be focused on business needs and perceived business risk. Good objectives are measurable and achievable within the development project schedule.

General

This section describes what is being tested, such as the features of a specific application or product, its interfaces, and integration with other features. Also, identify those features that will not be tested and the rational for “why” they are not being tested.

Identify the business expert who can assist the testing team with designing, executing, and interpreting tests in the correct business context.

Identify the technology expert who can assist the testing team with building and executing tests correctly in the target technology environment.

Identify the sources of test data and the amount of effort necessary to acquire data for the testing environment. Many times, it is most cost effective from a testing perspective and easiest from a data preparation perspective to use copies of production files and databases.

The approach should be described in sufficient detail to permit identification of the major testing tasks and the estimation of the time required to do each one.

Identify all of the artifacts that will be static tested.

Specify whether the units are tested using White Box or Black Box testing techniques.

Definition:

Specify the minimum degree of comprehensiveness desired. Identify the techniques which will be used to judge the comprehensiveness of the testing effort (for example, determining which statements have been executed at least once). Specify any additional completion criteria (for example, error frequency). The techniques to be used to trace requirements should be specified.

Participants:

List the names of individuals/departments who would be responsible for Unit Testing.

Methodology:

Describe how unit testing will be conducted. Who will write the test scripts for the unit testing, what would be the sequence of events of Unit Testing and how will the testing activity take place?

Definition:

List what is your understanding of System and Integration Testing for your project.

Participants:

Who will be conducting System and Integration Testing on your project? List the individuals that will be responsible for this activity.

Methodology:

Describe how System & Integration testing will be conducted. Who will write the test scripts for the unit testing, what would be sequence of events of System & Integration Testing, and how will the testing activity take place?

Definition:

List what is your understanding of Performance Testing for your project.

Participants:

Methodology:

Describe how Performance testing will be conducted. Who will write the test scripts for the testing, what would be sequence of events of Performance Testing, and how will the testing activity take place?

Definition:

The purpose of acceptance test is to confirm that the system is ready for operational use. During acceptance test, end-users (customers) of the system compare the system to its initial requirements.

Participants:

Who will be responsible for User Acceptance Testing? List the individuals' names and responsibility.

Methodology:

Describe how the User Acceptance testing will be conducted. Who will write the test scripts for the testing, what would be sequence of events of User Acceptance Testing, and how will the testing activity take place?

Definition:

Regression testing is the selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still works as specified in the requirements.

Participants:

Methodology:

Define the types of workstations to be tested.

Define the network requirements and the connectivity to be tested.

Specify both the necessary and desired properties of the test environment. The

Identify special test tools needed. Identify any other testing needs (for example, publications or office space). Identify the source of all needs which are not currently available to your group.

Problem Reporting

Document the procedures to follow when an incident is encountered during the testing process. If a standard form is going to be used, attach a blank copy as an "Appendix" to the Test Plan. In the event, you are using an automated incident logging system, write those procedures in this section.

Change Requests

Document the process of modifications to the software. Identify who will sign off on the changes and what would be the criteria for including the changes to the current product. If the changes will affect existing programs, these modules need to be identified.

Identify all software features and combinations of software features that will be tested.

To provide context for “Features To Be Tested”, insert the domain class model, use case diagrams, and high level use case description in a table with use case number, actor(s), use case name, and a brief description.

This section contains 15 detailed test cases. Paste the test cases in section 10.

Transaction Flow Testing

Provide the sequence of transaction screens with a description of each screen. Reference the use cases for the transaction screens.

Database Testing

1) Describe the database design validation by successfully performing application data manipulation using SQL scripts.

Identify all features and significant combinations of features which will not be tested and the reasons.

Specify the staff members who are involved in the test project and what their roles are going to be (for example, Mary Brown (User) compile Test Cases for Acceptance Testing). Identify groups responsible for managing, designing, preparing, executing, and resolving the test activities as well as related issues. Also identify groups responsible for providing the test environment. These groups may include developers, testers, operations staff, testing services, etc.

Major Deliverables

Identify the deliverable documents. You can list the following documents:

· Test Plan

· Test Cases

· Test Incident Reports

· Test Summary Reports

The detailed test plan schedule will be in a separate document.

Identify the high-risk assumptions of the test plan. Specify contingency plans for each (for example, delay in delivery of test items might require increased night shift scheduling to meet the delivery date). Use the Risk Table from lecture material.

List the Automation tools you are going to use. List also the Bug tracking tool here.

Specify the names and titles of all persons who must approve this plan. Provide space for the signatures and dates.

Name (In Capital Letters) Signature Date

2.

3.

4.

End.