You are on page 1of 16

ABC Corp Test Strategy

Version 1.0

Prepared By Name Role Signature Date


abci Test Lead

Reviewed by
Xyz Project Lead

Approved By
Cdf Project Lead

Table of Contents
1.0 Overview 3
3 3 3 4 4 4 4 4 1.1 Purpose & Scope 1.2 System Description 1.3 Testing Scope 1.3.1 In Scope 1.3.1.1. System Testing 1.3.1.2. Regression Testing 1.3.1.3. Performance Testing 1.3.2 Out of scope

2.0

Test Criteria

6
6 6 6 6 7 7 7 7

2.1 System testing 2.1.1 Entry Criteria 2.1.2 Exit Criteria 2.1.3 Suspension and Resumption Criteria 2.2 Regression Testing 2.2.1 2.2.2 2.2.3 Entry Criteria Exit Criteria Suspension and Resumption Criteria

3.0

Test Strategy

8
8 8 9 9

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

4.0 5.0 6.0 7.0 8.0 9.0

Problem Reporting and Data Recording Risk and mitigation Test Deliverables Critical Success Factors Assumptions, Dependencies and Constraints References

10 11 12 13 14 15 16

10.0 Change Log

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 Wave 1

Test Cycle Cycle 1 Cycle 2

Testing activity System Testing - execution of all test cases prepared for Wave 1 Defects Retesting & Regression testing of Wave 1 regression test cases

System Testing Execution of all test cases prepared for Wave 2 Wave 2 Cycle1 Defects retesting Regression testing of Wave 1 & Wave 2 test cases Cycle 2

1.3.1

In Scope System Testing

1.3.1.1.

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.

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

Wave 2 Certification Customer Feedback Reports Spec Administration Order Entry & Processing

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.

User Acceptance testing will be performed by MPF

2.0 Test Criteria


2.1
2.1.1

System testing
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
S.No 1

Suspension and Resumption Criteria


Suspension Criteria Non-availability of the application Resumption Criteria Availability application of the

Showstopping defects, which prevent further testing along any path. All the possible test cases have been tested with the failure notified and the fixes for the same have not arrived for re-testing. Non availability of test data (Not specific to test cases) Test environment issues which prevents further tests

Show stopper is rectified

Arrival of build with fixed defects

After loading the test data

Environmental issues are fixed

2.2
2.2.1

Regression Testing
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
S.No 1

Suspension and Resumption Criteria


Suspension Criteria Showstopping defects, which prevent further testing along any path. All the possible test cases have been tested with the failure notified and the fixes for the same have not arrived for retesting. Non availability of test data (Not specific to test cases) Resumption Criteria Show stopper is rectified

Arrival of build with fixed defects

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 Additional Scope or new CRs requested by MPF during Test 1 Planning and modification of functionality after preparation and review of testing artifacts. System Test Entry Criteria is not 2 met Have checkpoints leading upto the stage of system testing and making sure that all entry criteria are met Technical Suggested Mitigation The testing time-lines may have to be revised based on additional efforts arrived. Risk Category Technical

A slip in the development schedule The Testing team will closely in one or the other phases could monitor the progress of the result in a subsequent slip in the development teams and escalate test phase. anticipated delays to the Project Manager/Team Leads in advance. 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. Make sure unit testing is done by the development team before handing over the application for system testing. Application latency Response time of the application should be well within the acceptable limit

Schedule

Schedule

Too many critical defects found in system testing 5

Technical

Technical

6.0 Test Deliverables


P2Softech will provide the following deliverables in each of the testing phases Testing Phase Test Planning Test Design Deliverables Test Strategy Updated Requirement Traceability Matrix Test Cases for all the modules Test Execution Test Result logs Defect logs Test Reporting Delivery Weekly Test Progress Status 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 V1.0 V1.1 Changes made

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

<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

You might also like