Skip to main content

Test Plan

Software Test Plan

 

Revision History

 

A – Added, M – Modified, D – Deleted

S.No. Version No. Brief description of change (Page Num, Change (A,M,D)) Prepared By
– Name
– Date
Reviewed By
– Name
– Date
Approved By
– Name
– Date
1 4.2 4 – M – Change in version, scope, Purpose is changed. Srinivas

01-Apr-2015

Shyam

01-Apr-2015

Shyam

01-Apr-2015

2 4.3 4 – M – Change in version, scope, Purpose is changed. Srinivas

23-Dec-2015

Shyam

23-Dec-2015

Shyam

23-Dec-2015

 

Table of Contents

1.0  Introduction……………………………………………………………………………………………….. 1

1.1 Purpose………………………………………………………………………………………………… 1

1.2 Intended Audience…………………………………………………………………………………… 1

1.3 Acronyms and Definitions…………………………………………………………………………. 1

1.4 References…………………………………………………………………………………………….. 1

2.0  Test Scope………………………………………………………………………………………………… 2

2.1 Functions and Features to be tested……………………………………………………………. 2

2.2 Functions and Features that will not be tested……………………………………………….. 3

2.3 Deliverables…………………………………………………………………………………………… 3

2.4 Assumptions………………………………………………………………………………………….. 3

2.5 Dependencies………………………………………………………………………………………… 4

2.6 Constraints…………………………………………………………………………………………….. 4

3.0  Test Strategy……………………………………………………………………………………………… 5

3.1 Test Approach………………………………………………………………………………………… 5

3.1.1 Sanity Testing……………………………………………………………………………. 5

3.1.2 Functional Testing………………………………………………………………………. 5

3.1.3 Regression Testing…………………………………………………………………….. 6

3.2 Testing Cycles………………………………………………………………………………………… 6

3.3 Defect Classification………………………………………………………………………………… 6

3.4 Test Planning and Scheduling…………………………………………………………………….. 8

3.5 Size Estimates………………………………………………………………………………………… 8

3.6 Effort Estimates……………………………………………………………………………………… 8

3.7 Project Phases and Milestones…………………………………………………………………… 9

3.8 Risks & Contingencies……………………………………………………………………………… 9

4.0  Test Environment Setup…………………………………………………………………………. 10

4.1 Pre-requisites………………………………………………………………………………………… 10

4.2 Test Environment Set-up Procedure…………………………………………………………… 10

4.3 Test Bed Layout…………………………………………………………………………………….. 10

4.4 Compatibility Matrix……………………………………………………………………………….. 10

5.0  Project Monitoring & Control………………………………………………………………….. 11

5.1 Project Stakeholders………………………………………………………………………………. 11

5.2 Project Communication Plan…………………………………………………………………….. 11

5.3 Status Reporting……………………………………………………………………………………. 12

5.4 Change Management………………………………………………………………………………. 12

6.0  Resources……………………………………………………………………………………………….. 13

6.1 Staffing……………………………………………………………………………………………….. 13

6.2 Hardware……………………………………………………………………………………………… 13

6.3 Software………………………………………………………………………………………………. 14

6.4 Test Tools……………………………………………………………………………………………. 14

7.0  Appendices……………………………………………………………………………………………… 15

7.1 Project artifacts…………………………………………………………………………………….. 15

7.2 Customer supplied artifacts……………………………………………………………………… 15

 

1.0         Introduction

MarketPlaces is the first real time pricing and trading platform for the most actively traded U.S. corporate bonds. Two-way spreads are updated online continuously throughout the day by up to Eighteen leading dealers. This creates a level of price transparency; market depth and liquidity never before experienced in the institutional credit markets.

1.1   Purpose

This document is a Test Plan for the ABC.COM modules. This Test Plan is to meet the following objectives:

  • Recommend and describe the test strategy and approach to testing of the ABC.COM
  • Identify the various resources required for the successful completion of this project.
  • Identify existing information and the software components that should be tested.
  • List the functions and features to be tested and not to be tested.
  • List all the deliverables.

1.2   Intended Audience

The information in this document should be useful to the following groups:

  • QA (Quality Assurance)
  • BA (Business Analyst)

1.3   Acronyms and Definitions

MP      : MarketPlaces

TSM     : Technical Services Manager

1.4   References

Please refer ABC Pvt.Ltd – Project Plan QA & Testing (V 5.0).doc

2.0         Test Scope

Create test cases based on the Specs and by going through the application provided by MarketPlaces and create test cases based on the Resolved CMS items

Scope of the project is limited to testing of MarketPlaces Trading system purely depending on the information provided in the Specs provided by the MarketPlaces.

Testing involves Sanity, Functionality and Regression testing.

2.1   Functions and Features to be tested

Sl.No. Features to be tested Probability of Failure (1-5) Impact Value (1-5)
1 Module1 Regression Tests 5 1 For every release we need to test all the  features
2 Module1 GUI Validation Tests 5 3 For every release we need to test all the  features
3 Module2 GUI Validation Tests 5 3 For every release we need to test all the  features
4 Module2 Regression Tests 5 1 For every release we need to test all the  features
5 ModuleX Regression Tests 5 1 For every release we need to test all the  features

2.2   Functions and Features that will not be tested

Sl.No. Features that will not be tested Reasons for not testing
1 Pre Allocations Automated
2 Cancel / Amend Automated

2.3   Deliverables

S.No Deliverable Responsible Frequency
1 Test Plan Team Lead/POC For Every New Major Release
3 Test cases POC 1.For Every New Major Release

2.Need Basis

4 Test case summary Report POC For Every New Major Release
5 Bug Summary Report POC For Every New Major Release/Daily
6 Status reports POC Daily

2.4   Assumptions

XX Team is responsible only for Sanity, Functionality and Regression testing of Market Axess Trading system module.

2.5   Dependencies

  • MarketPlaces should set up the Test Environment
  • MarketPlaces should clarify the Product/spec related Issues
  • Network

2.6   Constraints

  • XX Team will run the Test Cases in MarketPlaces specified Environment (QA1/QA2)
  • XX Team will start Testing after Confirmation from MarketPlaces
  • MarketPlaces should provide the update specifications/product related changes to avoid the CMS rework

Test Strategy

2.7   Test Approach

The overall Testing strategy for MarketPlaces Trading System is described here.

Test Objective:

Perform the complete test of Trading System, which includes Sanity, Functionality, and Regression testing

Technique:

  • XX Team authors Test cases based on the Specifications
  • XX Team authored Test cases would be Peer Reviewed internally and Reviewed, Approved by MarketPlaces

Note: Test cases will be authored using XX Team Test Case Template and the same will be uploaded into QC

Completion Criteria:

  • XX Team would execute all the approved Test cases by MarketPlaces.
  • All identified defects will be reported to CMS (bug tracking tool).

2.7.1Sanity Testing

Test Objective: ·         Ensure that all the required messages are getting received for all the respective components.
Technique: ·         As per the test cases that are derived using Functional Documents /Business Rules/Application to verify the following:

·         The expected results occur when valid data is used.

Completion Criteria: ·         Every message is correctly received in all the respective components

2.7.2Functional Testing

Functional testing of System will be done as part of the full-blown testing of the build available to QA, by executing previously authored and reviewed test cases. The functional testing will consider all requirements for test that can be traced directly to the system test plan for the MarketPlace Trading System in order to verify proper data acceptance, processing, and retrieval

This testing will be based on black box technique; that is verifying the application and its internal processes by interacting via the Graphical User Interface (GUI) and analyzing the output or results.

No specific test cases will be written with the intent of exercising any particular piece of code i.e. white-box testing will not be done for any part of the application.

Identified below are outline of the testing recommended for the application

Test Objective: ·         Ensure proper target-of-test functionality, including navigation, data entry, processing, and retrieval.
Technique: ·         Execute test cases that are derived using Functional Documents/Business Rules/Application to verify the following:

·         The expected results occur when valid data is used.

·         Each business rule is properly applied.

·         The appropriate error or warning messages are displayed when invalid data is used.

Completion Criteria: ·         All planned tests have been executed.

·         All identified defects have been addressed.

2.7.3Regression Testing

 

Regression testing of the system will be done basically when any of the bugs reported are fixed and the new build is released with those fixed bugs. Also the basic functionality of the system is covered

 

Test Objective: ·         Ensure proper functionality, processing, and retrieval of the data entered. The bugs pointed to the particular release are fixed
Technique: ·         Execute test cases that are failed because of the functional testing:

·          The expected results occur when valid data is used.

·         Each business rule is properly applied.

·         The appropriate error or warning messages are displayed when invalid data is used.

Completion Criteria: ·         All the failed test cases pointed to the particular release are fixed

·         All identified defects if found are addressed.

 

 

2.8   Testing Cycles

 

Testing Cycle Testing Types Testing Scope
For Every Release Sanity, Retesting of CMS items, Functional and Regression Testing. As specified by the Client

 2.9   Defect Classification

 

Severity Type Categorization Criteria
Critical Workstation A Critical issue where a major system component is completely broken. There is no workaround and testing cannot continue for that component.
Critical Server A Critical issue where a large piece of functionality of a component is completely broken. There is no workaround and testing cannot continue for that functionality
Major A major issue where a large piece of functionality is not working properly. There is a workaround, however, and testing can continue
Medium A medium issue where a piece of functionality is not working properly. There is a workaround, however, and testing can continue
Low A minor issue that imposes some loss of functionality, but for which there is an acceptable and easily reproducible workaround. Testing can proceed without interruption
Enhancements Enhancements to make the system to make more robust and User-friendly.


2.10    Test Planning and Scheduling

2.11      Size Estimates

S.No. Deliverable Size
1 Test Cases Execution BL 5.2.1 1711
2 Test Cases Execution BL 5.3.0 2301
3 Test Cases Execution BL 5.4.0 6765
4 Test Cases Execution BL 5.4.1 3300
5 Test Cases Execution BL 5.5.0 6283
6 Test Cases Execution BL 5.5.1 2928
7 Test Cases Execution BL 5.6.0 2500
8 Test Cases Execution BL 5.7.0 3545
9 Test Cases Execution BL 5.8.0 7234
10 Test Cases Execution BL 5.9.0 3477
11 Test Cases Execution BL 6.0.0 3861
12 Test Cases Execution BL 6.1.0 2824

 

2.12      Effort Estimates

 

S. No Release Effort (person days)
1 BL 5.2.1 20 Business Days – 100 Person Days
2 BL 5.3.0 29 Business Days – 145 Person Days
3 BL 5.4.0 60 Business Days – 300  Person Days
4 BL 5.4.1 54  Business  Days – 270 Person Days
5 BL 5.5.0 43 Business Days – 258 Person Days
6 BL 5.5.1 18 Business Days – 108 Person Days
7 BL 5.6.0 20 Business Days – 100 Person Days
8 BL 5.7.0 49 Business Days – 245 Person Days
9 BL 5.8.0 80 Business Days – 400 Person Days
10 BL 5.9.0 52 Business Days – 260 Person Days
11 BL 6.0.0 28 Business Days- 140 Person Days
12 BL 6.1.0 84 Business Days – 420 Person Days

 

 

 

Project Phases and Milestones

Risks & Contingencies

  • Lack of personnel resource when testing is to begin.

 

  • Lack of availability of required hardware, software, data or tools.

 

  • Late delivery of the software, hardware or tools.

 

  • Delay in training on the application and/or tools.

 

  • Changes to the original requirements or designs.

 

 

1.0     Test Environment Setup

1.1   Pre-requisites

There is no Environment set up to be done here in XX Team; everything is done at Clients end

1.2   Test Environment Set-up Procedure

N/A

1.3   Test Bed Layout

N/A

1.4   Compatibility Matrix

N/A

 

2.0     Project Monitoring & Control

2.1   Project Stakeholders

 

Activity/Phases Client POC R&R TSM R&R PL/TL R&R Team R&R
All the Phases Ravi Shankar Ram Singh Venu Gopal

Lakshmipathi

Venkat Goud

Atul Sharma

 

2.2   Project Communication Plan

 

Client & Offshore team

Activity Communication Mode & Channel used Frequency Role and Responsibilities Escalation Records
Status Reporting Email, Teleconferencing, Yahoo chat Daily 1.Role of Client is to assign tasks in systematic manner and Offshore team has to follow and execute tasks accordingly

2.All the team members and Client POC to ensure that the issues are clarified and everyone is in sync with respect to the progress of the project

Client-CSM-TSM-Team Yahoo Chat Sessions, MOM, Daily Status Report
Issue Handling Email, Teleconferencing, Yahoo chat On Need Basis Email
Quality Reporting Email 1.After Every Release Email
Client Feedback Email, Teleconferencing, Yahoo chat 1.Quarterly

2.Need Basis

Email

 

 

 

 

 

 

 

PL/TL & Offshore Team

Activity Communication Mode & Channel used Frequency Role and Responsibilities Escalation Records
Status Reporting Mail Daily All the team members and PL/TL, to ensure that the project is running smoothly PL/TL-Team Email
Issue Handling Mail On Need Basis All the team members and PL/TL, to ensure that the project is running smoothly PL/TL-Team Email
Work Allocation Mail Daily All the team members and PL/TL, to ensure that the project is running smoothly PL/TL-Team Email

 

Onsite Team & Offshore Team

Activity Communication Mode & Channel used Frequency Role and Responsibilities Escalation Records
Status Reporting Mail Daily Onsite team and Offshore team members  ensure that the project is running smoothly Onsite team-Offshore team Mail
Issue Handling Email, Teleconferencing, Yahoo chat On need basis Onsite team and Offshore team members  ensure that the project is running smoothly Onsite team-Offshore team Mail

2.3   Status Reporting

<Mention the mode and frequency of Status Reporting to the stakeholders>

Report Title Frequency Mode of reporting
Daily Status Report Daily Mail
Test Summary Report After Every Release Mail
Bug Summary Report After Every Release Mail

 

2.4   Change Management

N/A

 

3.0         Resources

3.1   Staffing

Role Responsabilités
AVP Project Co-ordination
TSM Project Co-ordination
PL Project Co-ordination
TL/POC Testing according to work allocation.

Sending Daily/Weekly Client Communication of entire module

Bug Review and Reporting

Attending Client Call

Team Management

SSE Test according to Work Allocation and Bug Reporting
SE Test according to Work Allocation and Bug Reporting
ASE Test according to Work Allocation and Bug Reporting

 

3.2   Hardware

 

Resource Name / Type
Total Machine 6 Machines
Database Server N/A
—Server Name N/A
—Database Name N/A
Client Test PC’s N/A
—Include special configuration requirements N/A
Test Repository Quality Center
—Network or Subnet QA1:

 

QA2:

 

—Server Name QA1, QA2
Test Development PC’s
Any other details…. like VPN access details, External IP’s used, FTP details etc.  


3.3   Software

Software Name/Version Quantity / License
Cisco VPN 4.0.4
Oracle 9i(Client)
Tora 1.3.21(Oracle Client)
One Harness 1.1.0

3.4   Test Tools

 

Test Type Tool Version Access Information
Test Management Quality Center Ver 9.0 Through VPN
Defect Tracking Rational Clear Quest Ver 2002:05:00 Through VPN

 

Tool for functional testing N/A N/A N/A
Tool for performance testing N/A N/A N/A

 

4.0         Appendices

4.1   Project artifacts

Phase Document/Artifact Name Responsibility
Test Design Test Cases Team
Test Execution Daily Test Summary Report

Bug Reports

Test Summary Report (After Completion of the release)

Team