ABC Corp

Test Strategy

Version 1.0

Prepared By Reviewed by Approved By Name abci Xyz Cdf

Role Test Lead Project Lead Project Lead

Signature

Date

Table of Contents 1.0 Overview 3

1.1 Purpose & Scope 3 1.2 System Description 3 1.3 Testing Scope 3

1.3.1 In Scope 4 1.3.1.1. System Testing 4 1.3.1.2. Regression Testing 4 1.3.1.3. Performance Testing 4 1.3.2 Out of scope 4

2.0 Test Criteria 6

2.1 System testing 6 2.1.1 Entry Criteria 6 2.1.2 Exit Criteria 6 2.1.3 Suspension and Resumption Criteria 6

2.2 Regression Testing 7 2.2.1 Entry Criteria 7 2.2.2 Exit Criteria 7 2.2.3 Suspension and Resumption Criteria 7

3.0 Test Strategy 8

3.1 System Testing (Functional Testing) 8 3.2 Regression Testing 8 3.3 Test Data 9 3.4 Testing Tools 9

4.0 Problem Reporting and Data Recording 10

5.0 Risk and mitigation 11

6.0 Test Deliverables 12

7.0 Critical Success Factors 13

8.0 Assumptions, Dependencies and Constraints 14

9.0 References 15

10.0 Change Log 16

1.0 Overview

1.1 Purpose & Scope

The purpose of the Test strategy is to decide and define the approach for testing to be performed on the Visibility System.

1.2 System Description

The VISION System at MPF is used to manage the entire life of an order from customer definition to order entry and processing to payment collections. The following key tasks are accomplished by the current system and related peripheral systems:

� Marketing – Rebate and Commissions

� Customer Management

� Credit Management

� Order Entry and Processing

� Pricing

� Inventory Management

� Shipping & Billing

� Quality (COA)

� Accounts Receivables

� Collection and Cash Application

� Feedback Management

� Returns Management

� Sample Order Fulfillment

� Reporting and Dashboards

� Engineering/Configuration and Product Master Management

� Packaging

� Master Table Maintenance

� System and Security

An approach for the manual Functional Testing of the Visibility System is presented below.

1.3 Testing Scope

This section will primarily detail all the applications in scope for P2Softech in each of the two waves planned.

Wave Test Cycle Testing activity

Cycle 1 System Testing - execution of all test cases prepared for Wave 1 Wave 1

Cycle 2 Defects Retesting & Regression testing of Wave 1 regression test cases

Cycle1

System Testing - Execution of all test cases prepared for Wave 2 Wave 2

Cycle 2

Defects retesting Regression testing of Wave 1 & Wave 2 test cases

1.3.1 In Scope

1.3.1.1. System Testing

P2Softech team will be involved in preparing and executing functional test cases for the VISION system in two waves. The modules that will be covered in each of the waves are:

System test cases prepared for all wave 1 modules will be executed as part of the cycle 1. Similarly, system test cases prepared for all wave 2 modules will be executed as part of the first test cycle of wave 2.

1.3.1.2. Regression Testing

After the first test cycle, a second round of testing will be done to ensure that the defects are fixed. The functional areas which were working fine in previous test cycle but are otherwise affected by the fixes, will also be retested to make sure they continue to be working fine.

For wave 1, Regression test suite will be identified in the Test design phase to be executed as part of Test Cycle 2.

For Wave 2, the test case from Wave 1, which are dependent on Wave 2 modules will be identified in the design phase and these test cases will be executed as regression test cases as Cycle 2. Also, regression suite of Wave 2 test cases will be identified and executed as part of test cycle 2.

1.3.1.3. Performance Testing

A round of performance testing will be done before the UAT of each wave.

1.3.2 Out of scope

• Interface application functionality testing and VISION integration testing is an activity to be done by the onsite P2Softech team and MPF and will be out of testing scope at offshore.

Wave 1 Wave 2 Accounting Billing Credit Dashboard Inventory Jobs Marketing Packaging Shipping Table Maintenance Customer Management

Certification Customer Feedback Reports Spec Administration Order Entry & Processing

• User Acceptance testing will be performed by MPF

2.0 Test Criteria

2.1 System testing

2.1.1 Entry Criteria

System testing will be done for each Wave.

The Entry Criteria for the System Test will be on the completion of the following:

� Unit testing should have been completed

� Controlled Environment for testing to be made available to the system testing team before the scheduled start of testing

� Functional Test cases should be reviewed and signed off by offshore development team.

� The test environment should be ready and smoke test should be successful

� Test data should be available

2.1.2 Exit Criteria

The Exit Criteria for the System Test will be as follows:

� Execution of all functional test cases and completion of testing

� The status of all valid defects reported during the System Test is “Closed” or “Deferred”.

2.1.3 Suspension and Resumption Criteria

S.No Suspension Criteria Resumption Criteria

1 Non-availability of the application Availability of the application

2 Showstopping defects, which prevent further testing along any path.

Show stopper is rectified

3 All the possible test cases have been tested with the failure notified and the fixes for the same have not arrived for re-testing.

Arrival of build with fixed defects

4 Non availability of test data (Not specific to test cases)

After loading the test data

5 Test environment issues which prevents further tests

Environmental issues are fixed

2.2 Regression Testing

2.2.1 Entry Criteria

The Entry Criteria for the Regression Test will be on the completion of the following:

� Testing Cycle 1 should have been completed

� Controlled Environment for testing to be made available to the system testing team before the scheduled start of testing

� Regression Test cases for Wave 1 and Wave 2 should be reviewed and signed off by client

� The test environment should be ready

� Test data should be available

2.2.2 Exit Criteria

The Exit Criteria for the Regression testing will be as follows:

� Execution of all test cases and completion of testing.

� The status of all valid defects reported is “Closed” or “Deferred”.

2.2.3 Suspension and Resumption Criteria

S.No Suspension Criteria Resumption Criteria

1 Showstopping defects, which prevent further testing along any path.

Show stopper is rectified

2 All the possible test cases have been tested with the failure notified and the fixes for the same have not arrived for re-testing.

Arrival of build with fixed defects

3 Non availability of test data (Not specific to test cases)

After loading the test data

3.0 Test Strategy

3.1 System Testing (Functional Testing)

� System testing of the VISION system includes testing of complete set of

requirements for all the modules in Wave 1 and 2

� Test cases will be prepared for all the positive and negative flows for the

scenarios identified for testing

� All the Business rules will be covered by the test cases and it can be tracked

through Requirements Traceability Matrix.

� Test cases should be reviewed by the offshore development team and sign

off should be given on the same

� All the signed off system test cases will be executed and defects will be

logged against the failed test cases

� The Development team will help testing team in setting up the dedicated test

environment including any special licenses for the softwares.

� System Tests will validate the integration of all modules in a dedicated test

environment

� Defects will be reported to development team during test execution phase at

the end of the day

� The defect retesting round will be performed for the fixed defects and the

status updated into the test management tool on a daily basis

System Test Process and Test case preparation

The Testing Process will start with the Test requirements analysis, preparation of Test plan, Preparation of test cases, setting up the Test environment, installation of VISION system in a dedicated test environment. The baselined test cases will be executed and the results will be compared with the expected results. Any discrepancies will be logged as defects. P2Softech will be using an internal defect management tool Prolite for tracking defects. P2Softech will deploy resources at offshore for test case preparation activities.

3.2 Regression Testing

The Regression testing is carried out to ensure existing components in a system are not

impacted due to any changes being implemented in the system. This is achieved by verifying

a set of end to end scenarios in the system for functional correctness.

A Combined approach of certifying the individual components and testing the end to end

workflow scenarios will help in improving the overall release quality and reducing the number

of production defects post release.

Regression testing on the defects identified in previous cycles. During execution, testers perform following tasks:

� Retest the fixed defects and update the Test Log document with status.

� Execute the related test cases for the defects

� Execution of regression suite prepared for wave 1 and wave 2 in the respective phases.

� Update defect status in defect tracking tool Prolite.

� Track Defects and close defects after re-testing.

3.3 Test Data

Offshore Development team will ensure that the test data for system testing of the VISION system is available to P2Softech testing team before commencing the system testing.

3.4 Testing Tools

--NA—

4.0 Problem Reporting and Data Recording

� Recording of testing defects into the test tool identified for the project.

� Frequent Defect Meetings to discuss execution progress and defects

� 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.

� This allocation should be noted in the Defect management System, as should any and all actions taken by the development team to rectify or ameliorate the effects of the defect.

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

� Regression Testing will be done to ensure that the actions taken to rectify the defect have not produced any knock-on effects.

� Suitable analysis will be performed and appropriate tests will be re-run (or passed with a risk raised) for regression 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.

5.0 Risk and mitigation

Major risks involved in the project that can adversely impact quality and schedule have been listed

below.

S. No Risk Suggested Mitigation Risk Category

1

Additional Scope or new CRs

requested by MPF during Test

Planning and modification of

functionality after preparation and

review of testing artifacts.

The testing time-lines may have to

be revised based on additional

efforts arrived.

Technical

2

System Test Entry Criteria is not

met

Have checkpoints leading upto the

stage of system testing and making

sure that all entry criteria are met

Technical

3

A slip in the development schedule in one or the other phases could result in a subsequent slip in the test phase.

The Testing team will closely

monitor the progress of the

development teams and escalate

anticipated delays to the Project

Manager/Team Leads in advance.

Schedule

4

Delay in setting up dedicated test environment with necessary software licences

Make sure that the required test hardware/software is ready in advance and the test environment is setup much before the start of system testing.

Schedule

5

Too many critical defects found in system testing

Make sure unit testing is done by

the development team before

handing over the application for

system testing.

Technical

6

Application latency Response time of the application should be well within the acceptable limit

Technical

6.0 Test Deliverables

P2Softech will provide the following deliverables in each of the testing phases

Testing Phase Deliverables

Test Planning Test Strategy

Test Design Updated Requirement Traceability Matrix

Test Cases for all the modules

Test Execution Test Result logs

Defect logs

Test Reporting Weekly Test Progress Status

Delivery Test Summary Report

Defect Analysis Report

Testing Efficiency Metrics

7.0 Critical Success Factors

1. Clear and timely communication between onsite and offshore teams

2. Timely reviews and sign-offs by development team.

8.0 Assumptions, Dependencies and Constraints

1. Test environment set up for the VISION system will be owned by Offshore development team.

2. Offshore development team will be responsible for providing valid and real time data for testing.

9.0 References

The following were used as references to arrive at this high level test strategy:

All BREs, Wireframes, Project plan and use case documents.

10.0 Change Log

Version Number

Changes made

V1.0 <First version>

<If the change details are not explicitly documented in the table below, reference should be provided here>

Page no

Changed by

Effective date

Changes effected

V1.1

<If the change details are not explicitly documented in the table below, reference should be provided here>

Page no

Changed by

Effective date

Changes effected

V1.2