Master Test Plan
| Document | Master Test Plan |
| Author: | Ilmo Pitkänen |
| Version: | 1.0 |
| Date: | 19.2.2024 |
General information
A master test plan (MTP) is a high-level document that describes the overall testing strategy, objectives, and scope for a software project or product. It provides a comprehensive overview of the key decisions, resources, risks, and deliverables involved in the testing process. It also defines the relationship and coordination among different test levels, such as unit testing, integration testing, system testing, and acceptance testing. An MTP helps to ensure that the testing activities are aligned with the project goals and requirements, and that the quality of the software is verified and validated. You can find more information about MTPs from these sources:
- What are Master Test Plans & Level Test Plan? Examples, When to use.
- Developing a Test Plan: A Complete Guide
- What is a Test Plan in Software Testing? - TestLodge blog
- Why Every QA Team Needs To Create Master Test Plan?
- https://www.scaler.com/topics/software-testing/test-plan-in-software-testing/
- https://www.lambdatest.com/learning-hub/test-plan
Master Test Plan
1. Introduction
This document defines the methods, objectives and the end results of testing used in the future 16 project. Primarily the testing will focus on the features that the team will implement into the already existing Tukko traffic visualizer.
2. Test Objectives
The main objective of the testing will be to ensure the quality of the features and to make sure that they function as intended.
3. Test Items
The software that is to be tested is the Tukko traffic visualizer.
4. Features to be Tested
The following features will be tested.
5. Features not to be Tested
Currently all features will be tested.
6. Approach
The selected approach will include functional, performance, security and availability testing that will mostly be done manually.
7. Item Pass/Fail Criteria
- The feature works as it is defined
- The feature doesn't disrupt the software
- The feature doesn't have major bugs
8. Suspension Criteria and Resumption Requirements
Testing will be suspended if the feature is put on hold or if it is too time consuming.
Testing will be resumed if problems will the previous testing are solved.
9. Test Deliverables
Testers will deliver test reports about the tests they have performed. Testers also return bug reports if any were discovered during testing.
10. Testing Tasks
Preparation task will include finishing the feature into a testable version and defining the area which will be tested. The testing itself will require the feature to be tested and the results to be documented.
11. Environmental Needs
Software needs include Tukko and the testing tools. Hardware requirements include the server on which Tukko is hosted on.
12. Responsibilities
Testers will primarily do the testing and reporting. Developers are responsible for fixing any problems that might have been found. Team lead or other designated members are responsible for reviewing the test results.
13. Staffing and Training Needs
No staffing needs are currently required. Members partaking in testing will need to know their role and in accordance learn the skills needed.
14. Schedule
Testing activities will begin on phase 2 once the implementation are ready to be tested. Deadline will be the 12.4 on gate 3.
15. Risks and Contingencies
- Testers or members assigned to testing get sick.
- Testing is too difficult or the knowledge how to do it is too low.
- The testing takes too long.
16. Approvals
The testing plan must be approved by the client and the team.