1) INTRODUCTION:

A brief Introduction about the project.

1.1) Description of this document:

This document is a test plan for the <Project Name> platform, produced by Quality Assurance. It describes the testing strategy and approach to testing. QA will use this document to validate the quality of this product. It also contains requirements of various resources required for the successful completion of the <Project Name> and associated products.

The focus of testing the <Project Name> is to support those new features that will allow easier deployment and maintenance of solutions built upon the -<Project Name> - and -<Its associated applications name>. This release of the -<Project Name> will also include legacy bug fixing, and redesigning or including missing functionality from previous release.

4.) Feature not to be tested:

5.) OBJECTIVES:

The objective of this <Project Name> Test Plan is to define the procedures and logistics necessary to test the functionality of <Project Name> and applications associated with the <Project Name>.

The following objectives were incorporated into the test plan:

● Provide a formal testing process

● Test each Tier of requirement.

● Document the results of each test.

● Collect issues from the tests.

●Provide verifiable documentation that the concept, as developed, is functional.

●To test the functionality of <Project Name> and intended working of the same.

6.) Testing Personnel’s:

The testing will require participation of most of the personnel assigned to the project in order to operate and oversee the <Project Name>. To assist in coordination and documentation.

A dedicated testing team will be needed that will have no other duties during the testing period. This test team will oversee the testing. Optimally, the test team will consist of one team of at least four testers.

This team will consist of —

1.) Name 1.

2.)

Name 2.

3.)

Name 3.

4.)

Name 4.

Recruitment Required:

7.) Equipment (s) / Tools Required:

The <Project Name> Test Phase will require the following resources:

● <Project Name> Test environment.

● Proactive chat system.

● More than one land line phone number for SMS and Call tracking

●Tools for Load and stress testing [Tool yet to be decided].. OR Load Runner.

●Basic training on Tools used.

8.) Classification of Bugs:

● Blocker: This bug prevents developers from testing or developing the software.

● Critical: The software crashes, hangs, or causes you to lose data.

● Major: A major feature is broken.

● Normal: It's a bug that should be fixed.

● Minor: Minor loss of function, and there's an easy work around.

● Trivial: A cosmetic problem, such as a misspelled word or misaligned text.

● Enhancement: Request for new feature or enhancement.

9.) Bugs Priority List:

Priority

Priority Level

Priority Description

5

Must fix

Must be fixed immediately;

the product cannot ship with

This bug.

4

Should fix

Should be fixed as soon as

possible or else it will ruin the

Company’s reputation.

3

Fix

Fix it when it does not delay

The shipping date.

2

Low Priority

Fix it after all other higher levels are done.

1

Trivial

Fix it to make the product

Perfect.

10.) Error Management:

● During tests, errors will be recorded as they are detected on Error Report forms.

● Errors should be strictly turned around by Bugs Fixing Team and reported back to QA.

11.) SOFTWARE RISK ISSUES:

Identify what software is to be tested and what the critical areas are, such as:

A. Delivery of a third party product.B. Ability to use and understand product/package/tool, etc.D. Extremely complex functions.E. Modifications to components with a past history of failure.F. Poorly documented modules or change requests.

There are some inherent software risks such as complexity; these need to be identified. They include :

12.) STAFFING AND TRAINING NEEDS :

Training on the application/system.

Training for any test tools to be used/ required.

13.) Schedule:

APPROACH:

It is hoped that there will be at least one full time independent test team for system/Load testing. However, with the time line constraint established to one month; most testing will be done by the test team with the development team’s participation.

UNIT Testing:

Will be done by the developer and will be approved by the development team leader.

ACCEPTANCE Testing:

UAT shall be performed by the actual end users with the assistance of the project manager. Applicaions will enter into Acceptance test after all critical and major defects have been corrected. An application may have one or more major defect as long as it does not impede testing or performance of the application. Prior to final completion of acceptance testing, all open critical and major defects MUST be corrected and verified by the Customer test representative.

14.) After Final Test:

To generate a final test report and wait for sign-off. The bugs should be reported as clear and complete as possible. The informal feedback of these tests should be collected, evaluated and could lead to feature requests.