Test Startegy

Introduction

 The strategy describes the high level test schedules and the types of testing that are performed. The intended audience for this document is Quality Assurance, Development and Project Management teams and client.

Scope of Testing:

List out the functionalities that we are covering

Smoke Testing

Entry Criteria:

1. Unit Testing should be done with all Unit Test Cases should be Passed and ensure that it meets the initial requirements and prepare the way for further QA Team
2. Build should be deployed in QA Environment without any errors
3. QA Environment should be Up and running state
4. All the defects which are raised in previous build should be in fixed state in defect management tool
5. Smoke Test Cases should be in place

Exit Criteria:

1.  All the Smoke Test Cases should be Pass
2.  Test Results Captured
3.  Defects logged in defect management tool

 Functional Testing

Entry Criteria:

1.             Smoke Test Cases should be PASS

            

Regression

Integration Testing

System Testing

User Acceptance Testing

Pre production

Performance Testing

Work Plan:

Schedules and Timeliness for each phase of Testing

Phase	Start Date	End Date
Smoke Testing

Test Data Selection:

 Below are the popular method for selecting the test data and it is most important while doing the execution

1.             Random Testing – Generally this method is using for crash testing (robustness testing) – Will the system survive this input?

Define all input parameters – E.g Integer, real, string etc..

2.             Risk based Testing – Identify the Risk of not delivering a certain functionality

3.             User profile Testing – In this type of testing generate test that mirror the user's way of using system

4.             Bach's heuristic risk based testing  - Based on Tester's experience generate a generic risk checklist (things that are important to test), Risk Catalogue (things that often go wrong)

Defect Reporting and Data Recording:

·                     Record testing defects into the tool identified for the project (Portals)

·                     Review of Defects & its Maintenance in repository

·                     Frequent Defect Clarification/analysis is performed

·                     Each and every defect is assigned to a Developer. If there are any clarifications pertaining to these defects, it must be recorded in the Defect management system.

·                     Once the Development is satisfied that the defect has been fixed, a note is made on the defect management system that the component(s) affected by the defect are ready for re-testing.

·                     Only when re-test has been successfully completed with no critical failures the Testing will be signed-off.

·                     It is expected that defect discovery rates will eventually diminish as the testing and fixing progresses. This must be monitored closely as the application system goes through the different phases of testing.

Suspension and Resumption Criteria

S.No	Suspension Criteria	Resumption Criteria

Change Log:

Version No	Changes Made