Test Plan Template
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Test Plan Template as PDF for free.
More details
- Words: 1,428
- Pages: 9
Countrywide Home Loans
Production Technologies
Test Plan Template For Production Fix PCRs and Enhancements
Project: Name of project Version #: Revision # Date: Last update date Prepared By: Name of person who completed the template
Table of Revisions Revision
9158240.doc
Date
Author
Notes
2 of 9
10/17/2008
Table of Contents 1.0Scope................................................................................................................4 2.0Schedule ..........................................................................................................4 3.0Test Types.........................................................................................................5 4.0Environment.....................................................................................................5 5.0Resources ........................................................................................................6 (delete un-needed names)....................................................................................6 6.0 Roles and Responsibilities............................................................................6 QA Analyst.......................................................................................................................................................6
7.0 Tracking and Reporting..................................................................................6 8.0 Group Coordination Plan...............................................................................7 Developers.......................................................................................................................................................7
9.0 Deliverables.....................................................................................................7 10.0 Acceptance & Pass/Fail Criteria..................................................................8 Severity Levels.............................................................................................................................................8
11.0 Security Controls..........................................................................................8 12.0 Status and Reporting....................................................................................9 13.0 Risks & Constraints......................................................................................9 14.0 Assumptions.................................................................................................9 15.0 Approval(s)....................................................................................................9
9158240.doc
3 of 9
10/17/2008
Test Plan Template Test Plan Objectives This document outlines the objectives and activities for the Countrywide Quality Assurance (QA) Testing process. The purpose of this plan is to define the testing activities required to plan, prepare, and conduct testing. It is intended for use by the QA Team in understanding and carrying out test activities, evaluating the quality of test activities, and managing these activities through successful completion. Testing will be conducted to verify the following Business Requirements have been successfully coded and tested in the QA Environment: PASTE CLUES REQUIREMENT HERE
1.0 Scope ENTER YOUR TEST STRATEGY STATEMENT HERE CHART TO ASSIST WITH SCOPING UIS
CMD N/A
CLD Web
WLD CWBC
FSL N/A
UR
Edge and AdvantEdge (Streamlined Only)
N/A
Edge
Edge
LFXML
AdvantEdge (Prelim Only)
Edge
AdvantEdge - (Prelim Only)
N/A
Schedule (The underlined should be updated with the Release info you are working on) 2.0
Testing for AI Release 05.05.07 is scheduled for QA Testing to begin on 6/10/2005 and to be completed prior to the anticipated release to the Beta Environment on 7/1/2005:
9158240.doc
4 of 9
10/17/2008
3.0 Test Types Functional Testing will be executed using AI Test Tool to verify input and output of a CLUES submission. Functional testing uncovers what works, how it works, and whether it conforms to the Specification Document. Within Functional Testing are the following test subsets executed when applicable:
•
Reliability Testing: tests how well code handles failures, data integrity, safety, and security.
•
Scenario Testing: tests a group of data that may individually produce no defects but collectively may produce a variety of issues.
•
Specification-Based Testing: tests that the code adheres to the requirements outlined in the Specification Document.
•
Boundary Testing: tests the maximum and minimum values and any special exceptions when applied to web site calculations.
•
Regression Testing will be conducted on every build introduced into the QA Environment to ensure existing functionality has not been damaged.
•
For a detailed list of test scenarios, please see QII Test Scenarios
4.0 Environment LIST QA SERVER BEING USED AND ANY ADDITIONAL ENVIRONMENTAL SETTINGS THAT NEED TO OCCUR Any Environment Changes Checklist: Chang e
Environment
Description
Ini file changes: Database object changes: Store Procedure changes: Requires a dedicated server (list the one you are requesting): Requires a separate build: Requires late-to-production schedule (give reason & date, & "off" setting or procedure): Requires an early Alpha (give reason and date): BBE Script Update: .xslt updates (XML Mapper): Web Site updates: Mailers (Melissa data): Logging Server Updates: Config Server Updates: Clues Manager Server Updates:
9158240.doc
5 of 9
10/17/2008
Resources (delete un-needed names) 5.0
Brahatha Mohan Andrew Kennedy Aziz Jivani Yen Wong
6.0 Roles and Responsibilities QA Analyst •
Review Functional and Technical Requirements Documents.
•
Schedule Walkthrough Meeting with the System Analyst and the Assigned Developer.
•
Develop Test Plan and Test Scenarios.
•
Set up QA environment.
•
Migrate code to the QA environment.
•
Perform Integration testing: execute test scripts.
•
Document defects in Viper.
•
Perform Retests test scenarios.
•
Document test results.
•
Confirm exit criteria have been met and provide QA signoff.
QA Manager • Prepares status reports throughout the test cycle for the VP of QA. •
Reviews test documentation and plans.
•
Ensures testing will be completed by the anticipated date and notifies the VP of QA of any changes which may prevent successful completion of testing.
•
Serves as back up for all testing efforts and assists the QA Analyst if needed.
7.0 Tracking and Reporting
Tracking: Defect and time tracking will be reported in Viper on the QA Work Order.
Reporting Progress and statuses of test activities are reported to the Managers throughout the critical stages of testing.
9158240.doc
6 of 9
10/17/2008
8.0 Group Coordination Plan Developers The Developers are responsible for correcting defects and researching problems that arise during test sessions. The Developers correct any defects and unit test coding changes. Systems Analyst The Systems Analyst is responsible for providing a PCR Walkthrough answering all questions regarding the business requirements and will notify QA of any changes to the Functional or Technical Specification prior to or during the test cycle. The SA will provide continuing support throughout the test cycle until completion.
9.0 Deliverables
9158240.doc
QII Test Plan Test Case Input Files Test Case Output Results
7 of 9
10/17/2008
10.0 Acceptance & Pass/Fail Criteria Acceptance The following criteria must be met prior to moving the code to the Beta and Production Environments: • All scripts have been executed to completion. •
Analysis of test results indicates that the system meets the requirements set forth in the Functional Design Document.
•
There are no open showstopper defects.
•
The Managers have reviewed all outstanding defect reports and agree that none are serious enough to delay the delivery of software to the client.
Pass/Fail Criteria A defect is identified by the inability to meet the specifications defined by the requirements, documented in the approved Product Specification Document. The QA Analyst records the defects in the Defect Tracking Tool. The Software Development Team is responsible for analyzing and correcting the defect. Each defect is assigned a priority that is used by the Development Team to determine the repair order of the open defects. Severity Levels The established severity levels for this project for defect reporting are as follows: Showstopper Testing cannot continue and the execution of the current test cannot proceed unless this incident is corrected. No effective workaround exists, and if not corrected the incident would have a significant impact to the testing schedule. Code will not be moved into Production when a Showstopper cannot be downgraded to a High Level Defect. High Incidents that do not prevent the current test from continuing, but must be resolved. The current code can be implemented with a work around in place. Code may be moved into Production with a fix delivered in a future release. Medium These incidents identify changes that would provide a benefit, but due to risk or time constraints, must be made at a later date. Low Incidents that do not have any negative impact on the goals of testing or on production.
11.0 Security Controls Standard PT security controls will be put in place to ensure the borrower name and SSN has been changed to test data.
9158240.doc
8 of 9
10/17/2008
12.0 Status and Reporting QA Analyst
Notify the QA Manager when their test planning is complete. Notifies the QA Manager if their the test schedule is at risk. Provides status of testing to the QA Manager or VP of QA at any given time during the test cycle. Notifies the QA manager when completing a work order. QA Manager Notifies the VP of QA when test plans have been reviewed. Sends weekly statuses of all QA work orders for a specific Release.
13.0 Risks & Constraints Risk Due to the short test cycles allowed during a specific release, any code not delivered and Unit tested on the anticipated QA start date is at risk of not being fully tested. Constraints In the event code is delivered late, the analyst will review the changes being made and identify the risk of delivering the code with only high level testing. They will notify the QA Manager and the VP of QA of this risk. If proceeding high level testing will occur and the Analyst will identify any scenarios that were not tested due to the time constraint.
14.0 Assumptions It is assumed that any reader of this document will be familiar with standard PT SDLC practices and the use and management of Viper.
15.0 Approval(s) 15.1 Business Solution Owner & System Owner Acceptance and Sign-Off Concurrence by both the Business Solution Owner and System Owner that the Test Plan is accurate.
Business Solution Owner Name:
System Owner Name:
Signature:
Signature:
Date:
Date:
9158240.doc
9 of 9
10/17/2008
Production Technologies
Test Plan Template For Production Fix PCRs and Enhancements
Project: Name of project Version #: Revision # Date: Last update date Prepared By: Name of person who completed the template
Table of Revisions Revision
9158240.doc
Date
Author
Notes
2 of 9
10/17/2008
Table of Contents 1.0Scope................................................................................................................4 2.0Schedule ..........................................................................................................4 3.0Test Types.........................................................................................................5 4.0Environment.....................................................................................................5 5.0Resources ........................................................................................................6 (delete un-needed names)....................................................................................6 6.0 Roles and Responsibilities............................................................................6 QA Analyst.......................................................................................................................................................6
7.0 Tracking and Reporting..................................................................................6 8.0 Group Coordination Plan...............................................................................7 Developers.......................................................................................................................................................7
9.0 Deliverables.....................................................................................................7 10.0 Acceptance & Pass/Fail Criteria..................................................................8 Severity Levels.............................................................................................................................................8
11.0 Security Controls..........................................................................................8 12.0 Status and Reporting....................................................................................9 13.0 Risks & Constraints......................................................................................9 14.0 Assumptions.................................................................................................9 15.0 Approval(s)....................................................................................................9
9158240.doc
3 of 9
10/17/2008
Test Plan Template Test Plan Objectives This document outlines the objectives and activities for the Countrywide Quality Assurance (QA) Testing process. The purpose of this plan is to define the testing activities required to plan, prepare, and conduct testing. It is intended for use by the QA Team in understanding and carrying out test activities, evaluating the quality of test activities, and managing these activities through successful completion. Testing will be conducted to verify the following Business Requirements have been successfully coded and tested in the QA Environment: PASTE CLUES REQUIREMENT HERE
1.0 Scope ENTER YOUR TEST STRATEGY STATEMENT HERE CHART TO ASSIST WITH SCOPING UIS
CMD N/A
CLD Web
WLD CWBC
FSL N/A
UR
Edge and AdvantEdge (Streamlined Only)
N/A
Edge
Edge
LFXML
AdvantEdge (Prelim Only)
Edge
AdvantEdge - (Prelim Only)
N/A
Schedule (The underlined should be updated with the Release info you are working on) 2.0
Testing for AI Release 05.05.07 is scheduled for QA Testing to begin on 6/10/2005 and to be completed prior to the anticipated release to the Beta Environment on 7/1/2005:
9158240.doc
4 of 9
10/17/2008
3.0 Test Types Functional Testing will be executed using AI Test Tool to verify input and output of a CLUES submission. Functional testing uncovers what works, how it works, and whether it conforms to the Specification Document. Within Functional Testing are the following test subsets executed when applicable:
•
Reliability Testing: tests how well code handles failures, data integrity, safety, and security.
•
Scenario Testing: tests a group of data that may individually produce no defects but collectively may produce a variety of issues.
•
Specification-Based Testing: tests that the code adheres to the requirements outlined in the Specification Document.
•
Boundary Testing: tests the maximum and minimum values and any special exceptions when applied to web site calculations.
•
Regression Testing will be conducted on every build introduced into the QA Environment to ensure existing functionality has not been damaged.
•
For a detailed list of test scenarios, please see QII Test Scenarios
4.0 Environment LIST QA SERVER BEING USED AND ANY ADDITIONAL ENVIRONMENTAL SETTINGS THAT NEED TO OCCUR Any Environment Changes Checklist: Chang e
Environment
Description
Ini file changes: Database object changes: Store Procedure changes: Requires a dedicated server (list the one you are requesting): Requires a separate build: Requires late-to-production schedule (give reason & date, & "off" setting or procedure): Requires an early Alpha (give reason and date): BBE Script Update: .xslt updates (XML Mapper): Web Site updates: Mailers (Melissa data): Logging Server Updates: Config Server Updates: Clues Manager Server Updates:
9158240.doc
5 of 9
10/17/2008
Resources (delete un-needed names) 5.0
Brahatha Mohan Andrew Kennedy Aziz Jivani Yen Wong
6.0 Roles and Responsibilities QA Analyst •
Review Functional and Technical Requirements Documents.
•
Schedule Walkthrough Meeting with the System Analyst and the Assigned Developer.
•
Develop Test Plan and Test Scenarios.
•
Set up QA environment.
•
Migrate code to the QA environment.
•
Perform Integration testing: execute test scripts.
•
Document defects in Viper.
•
Perform Retests test scenarios.
•
Document test results.
•
Confirm exit criteria have been met and provide QA signoff.
QA Manager • Prepares status reports throughout the test cycle for the VP of QA. •
Reviews test documentation and plans.
•
Ensures testing will be completed by the anticipated date and notifies the VP of QA of any changes which may prevent successful completion of testing.
•
Serves as back up for all testing efforts and assists the QA Analyst if needed.
7.0 Tracking and Reporting
Tracking: Defect and time tracking will be reported in Viper on the QA Work Order.
Reporting Progress and statuses of test activities are reported to the Managers throughout the critical stages of testing.
9158240.doc
6 of 9
10/17/2008
8.0 Group Coordination Plan Developers The Developers are responsible for correcting defects and researching problems that arise during test sessions. The Developers correct any defects and unit test coding changes. Systems Analyst The Systems Analyst is responsible for providing a PCR Walkthrough answering all questions regarding the business requirements and will notify QA of any changes to the Functional or Technical Specification prior to or during the test cycle. The SA will provide continuing support throughout the test cycle until completion.
9.0 Deliverables
9158240.doc
QII Test Plan Test Case Input Files Test Case Output Results
7 of 9
10/17/2008
10.0 Acceptance & Pass/Fail Criteria Acceptance The following criteria must be met prior to moving the code to the Beta and Production Environments: • All scripts have been executed to completion. •
Analysis of test results indicates that the system meets the requirements set forth in the Functional Design Document.
•
There are no open showstopper defects.
•
The Managers have reviewed all outstanding defect reports and agree that none are serious enough to delay the delivery of software to the client.
Pass/Fail Criteria A defect is identified by the inability to meet the specifications defined by the requirements, documented in the approved Product Specification Document. The QA Analyst records the defects in the Defect Tracking Tool. The Software Development Team is responsible for analyzing and correcting the defect. Each defect is assigned a priority that is used by the Development Team to determine the repair order of the open defects. Severity Levels The established severity levels for this project for defect reporting are as follows: Showstopper Testing cannot continue and the execution of the current test cannot proceed unless this incident is corrected. No effective workaround exists, and if not corrected the incident would have a significant impact to the testing schedule. Code will not be moved into Production when a Showstopper cannot be downgraded to a High Level Defect. High Incidents that do not prevent the current test from continuing, but must be resolved. The current code can be implemented with a work around in place. Code may be moved into Production with a fix delivered in a future release. Medium These incidents identify changes that would provide a benefit, but due to risk or time constraints, must be made at a later date. Low Incidents that do not have any negative impact on the goals of testing or on production.
11.0 Security Controls Standard PT security controls will be put in place to ensure the borrower name and SSN has been changed to test data.
9158240.doc
8 of 9
10/17/2008
12.0 Status and Reporting QA Analyst
Notify the QA Manager when their test planning is complete. Notifies the QA Manager if their the test schedule is at risk. Provides status of testing to the QA Manager or VP of QA at any given time during the test cycle. Notifies the QA manager when completing a work order. QA Manager Notifies the VP of QA when test plans have been reviewed. Sends weekly statuses of all QA work orders for a specific Release.
13.0 Risks & Constraints Risk Due to the short test cycles allowed during a specific release, any code not delivered and Unit tested on the anticipated QA start date is at risk of not being fully tested. Constraints In the event code is delivered late, the analyst will review the changes being made and identify the risk of delivering the code with only high level testing. They will notify the QA Manager and the VP of QA of this risk. If proceeding high level testing will occur and the Analyst will identify any scenarios that were not tested due to the time constraint.
14.0 Assumptions It is assumed that any reader of this document will be familiar with standard PT SDLC practices and the use and management of Viper.
15.0 Approval(s) 15.1 Business Solution Owner & System Owner Acceptance and Sign-Off Concurrence by both the Business Solution Owner and System Owner that the Test Plan is accurate.
Business Solution Owner Name:
System Owner Name:
Signature:
Signature:
Date:
Date:
9158240.doc
9 of 9
10/17/2008
Related Documents
Test Plan Template
October 2019 33
Unit Test Plan Template
June 2020 12
Isa Test Plan Template
May 2020 11
Test Plan Template
November 2019 21
Test Plan Template-sayan
June 2020 3