MASTER TEST PLAN
MTP
Program/Initiative Number:Strategic Plan Program/Initiative Title:
Program/Initiative Year:
Project Title: / Project Number:
Marketing Project Number:
Author/Requester:
Contact List: Asterisk denotes approval required
Purpose: The Master Test Plan is to assist in, planning, monitoring and controlling the testing process. The Master Test plan is for shaping testing strategies. It also encompasses components used to manage software testing with the intent to find errors.
TABLE OF CONTENTS
Page Number
Cover Page 1
Table of Contents 2-3
Document Change Notice 4
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Document Responsibilities 4
1.3.1 Authors 4
1.3.2 Ownership 4
1.3.3 Required Reviewers 4
2. Approach 4
3. Schedule 5
4. Requirements Testing 5
4.1 Items to be Tested 5
4.2 Items not to be Tested 5
4.3 Approach 5
4.4 Test Deliverables 5
4.5 Responsibilities 5
4.6 Schedule 5
4.7 Risks and Contingencies 5
5. Design Testing 6
5.1 Items to be Tested 6
5.2 Items not to be Tested 6
5.3 Approach 6
5.4 Test Deliverables 6
5.5 Responsibilities 6
5.6 Schedule 6
5.7 Risks and Contingencies 6
6. Unit and Performance Testing 6
6.1 Items to be Tested 6
6.2 Items not to be Tested 6
6.3 Approach 6
6.4 Test Deliverables 6
6.5 Responsibilities 6
6.6 Schedule 7
6.7 Risks and Contingencies 7
7. Integration Testing 7
7.1 Items to be Tested 7
7.2 Items not to be Tested 7
7.3 Approach 7
7.4 Test Deliverables 7
7.5 Responsibilities 7
7.6 Schedule 7
7.7 Risks and Contingencies 7
8. System Testing 7
8.1 Items to be Tested 7
8.2 Items not to be Tested 7
8.3 Approach 8
8.4 Test Deliverables 8
8.5 Responsibilities 8
8.6 Schedule 8
8.7 Risks and Contingencies 8
9. Documentation Testing 8
9.1 Items to be Tested 8
9.2 Items not to be Tested 8
9.3 Approach 8
9.4 Test Deliverables 8
9.5 Responsibilities 8
9.6 Schedule 8
9.7 Risk and Contingencies 9
10. Usability Testing 9
10.1 Items to be Tested 9
10.2 Items not to be Tested 9
10.3 Approach 9
10.4 Test Deliverables 9
10.5 Responsibilities 9
10.6 Schedule 9
10.7 Risks and Contingencies 9
11. Acceptance Testing 10
11.1 Items to be Tested 10
11.2 Items not to be Tested 10
11.3 Approach 10
11.4 Test Deliverables 10
11.5 Responsibilities 10
11.6 Schedule 10
11.7 Risks and Contingencies 10
12. Approval 10
Document Change Notice
Document Version: / Description of Change:Date of Change:
1. Introduction
The Master Test Plan is to assist in, planning, monitoring, and controlling the testing process needed for the Master Test plan is needed for shaping testing strategies. It also encompasses components used to manage software testing with the intent to find errors.
1.1 Purpose
The goal is to implement a Master Test Plan (MTP) document (or series of documents) outlining project testing initiation which may be expanded and reviewed during a project to guide and control all testing efforts.
1.2 Scope
The scope of this project is broad and may apply to other projects. This MTP refers to testing procedures and extends them as necessary.
1.3 Document Responsibilities
The MTP is the primary means by which testing may be directed and controlled. It raises testing issues, defines testing work, coordinates testing efforts, and assigns and obtains resources. Document responsibilities will be portioned into three categories: Authors, Ownership and Required Reviewers.
1.3.1 Authors
Identify the authors in the group are responsible for managing, designing, preparing, executing, witnessing, checking, and resolving documentation.
1.3.2 Ownership
Identify the owners of the MTP that are responsible for managing, designing, preparing, executing, witnessing, checking, and resolving documentation. They will have full ownership of the MTP documentation. All revisions must be approved by the owners.
1.3.3 Required Reviewers
Reviewers will be responsible for reviewing all MTP documentation. This involves reliably capturing information on problems detected during testing or system operation and then analyzing and summarizing that information so that trends and significant events are recognized.
2. Approach
A draft of the MTP will be prepared during requirements definition phase. Tentative objectives should be apparent to all involved in the project. There will be a development for requirements-based and design-based coverage so they can be used to derive the design of test cases. There must be open reception to critiques in order to modify objectives as the project proceeds. There will be documentation on all agreed-upon objectives in the Master Test Plan.
3. Schedule
Schedules will be established for each system. Changes will be held and applied all at once at the designated interval. This will permit a single design review of all the proposed changes, it avoids having to change the same code multiple times, and allows a thorough systems and acceptance test to be carried out before the changes are made effective.
4. Requirements Testing
Requirement testing provides a systematic demonstration that all functions are available as specified.
4.1 Items to be Tested
Start up program by pressing space bar
Keyboard functionality
Error messages
Alpha entries
Numeric entries
Test product in DOS environment.
4.2 Items not to be Tested
Mouse (point and click) capabilities
Window operating functions
4.3 Approach
Requirements testing will be tested as functions are completed. There will be a function by function approach.
4.4 Test Deliverables
Hard copy test plan and expected results.
4.5 Responsibilities
The requirements testing responsibilities will belong to Quality Assurance. .
4.6 Schedule
Requirement testing will begin once there is a complete breakdown on business requirements and functionality.
4.7 Risks and Contingencies
Risk is taken if requirements are not present.
5. Design Testing
This basic technique consists of building a simplified representation or model of a selected design property and then using the model to explore (or test) the underlying design. The model permits testing to take place early in the design, before programming has started, and ensures that the design is sound (at least with respect to the aspect tested).
5.1 Items to be Tested
5.2 Items not to be Tested
5.3 Approach
Review Object-Oriented model class by class
5.4 Test Deliverables
Hard copy test plan and expected results.
5.5 Responsibilities
All Testers and Quality Assurance Manager.
5.6 Schedule
Testing will begin after the Object-Oriented database design has been completed.
5.7 Risks and Contingencies
Risks are taken if database is not stable before testing begins.
6. Unit and Performance Testing
Testing of individual programs as they are written.
6.1 Items to be Tested
6.2 Items not to be Tested
6.3 Approach
6.4 Test Deliverables
6.5 Responsibilities
6.6 Schedule
6.7 Risks and Contingencies
7. Integration Testing
This section contains the orderly progression of testing in which elements are combined and tested until the entire system has been integrated.
7.1 Items to be Tested
7.2 Items not to be Tested
7.3 Approach
Test all modules as they get completed and integrate them until all modules have been combined and tested.
7.4 Test Deliverables
Integrated test plan and the expected results.
7.5 Responsibilities
Quality Assurance will be responsible for all integration testing.
7.6 Schedule
Integration testing will begin after unit testing has been performed.
7.7 Risks and Contingencies
8. System Testing
This section contains testing of groups of programs. The system functions are exercised and the software is stressed to uncover its limitations and measure its full capabilities.
8.1 Items to be Tested
8.2 Items not to be Tested
8.3 Approach
Approach taken for system testing will be based on the versioning of the product.
8.4 Test Deliverables
8.5 Responsibilities
8.6 Schedule
8.7 Risks and Contingencies
9. Documentation Testing
This section pertains to the accuracy of the user documentation. The principal way of accomplishing this is the use of the user documentation to determine the representation of the prior system test cases. Also the user documentation should be the subject of an inspection, checking it for accuracy and clarity.
9.1 Items to be Tested
All specifications pertaining to the product being tested
Online documentation
Hard copy documentation
9.2 Items not to be Tested
Non-documentation functionality
9.3 Approach
Testing can begin once a function has been specified and documented for the product.
9.4 Test Deliverables
All documentation with fixes (corrected grammar, spelling etc).
9.5 Responsibilities
Quality Assurance and Developers will determine when the documentation is ready for testing.
9.6 Schedule
Documentation testing will begin once unit testing has begun and will continue through field testing.
9.7 Risk and Contingencies
Documentation is not completed when unit testing begins.
10. Usability Testing
This section pertains to finding human-factor problems. Each user interface should be tailored to the intelligence, educational background, and environmental pressures of the end user. Output must be meaningful. Error diagnostics must be straightforward. Syntax must be consistent along with conventions, semantics, format, style and abbreviations. Accuracy is vital, and should check to see if sufficient redundancy present in the input. Checking for the number of options used and not used. System must return some type of immediate acknowledgment to all inputs. Program should be easy to use.
10.1 Items to be Tested
Number of options to be used
Number of options not used.
Ease of use
Accuracy
Format
Style
Syntax
Redundancy
Abbreviations
Error messages
10.2 Items not to be Tested
10.3 Approach
10.4 Test Deliverables
Test plan
Results from testing
10.5 Responsibilities
Quality Assurance and Beta customers will be responsible for testing and reporting results to product management.
10.6 Schedule
Usability testing will begin with integration testing through field testing.
10.7 Risks and Contingencies
Experiment with the tools on the button bar. The “Heading” buttons allow you to quickly create logical divisions in your report. After creating several headings, the “Table of Contents” button will automatically generate a complete table of contents, including page numbers!
11. Acceptance Testing
Acceptance Testing is testing used to verify readiness for implementation or use. Its purpose is to provide the end user or customer with confidence and insurance that the software is ready to be used.
11.1 Items to be Tested
Major functions
Documentation
Procedures
11.2 Items not to be Tested
Nothing, everything must be tested!
11.3 Approach
Testing will begin once the entire system has been completed.
11.4 Test Deliverables
Acceptance Testing Checklist
Do’s and Don’ts
11.5 Responsibilities
Testing is performed by the Stakeholders who will report all findings to the Project Manager.
11.6 Schedule
11.7 Risks and Contingencies
12. Approval
Date Created: ~ ~ Current Document Date: ~ ~
Version # : ~ Page 1 of 10
Company Confidential CONTROLLED Printed copies are uncontrolled