Master Test Plan
| Document | Master Test Plan |
| Author: | Guan Xinyu |
| Version: | 0.1 |
| Date: | 12.02.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.lambdatest.com/learning-hub/test-plan
Master Test Plan
1. Introduction
The master test plan is describing the overall test strategy, objectives and scope of the project team Flying Hippos for Tukko, a traffic data visualization tool that utilizes the Public Transportation API.
2. Test Objectives
The testing goal of the Flying Hippos team is to improve a traffic data visualization product that utilizes public transportation APIs. The name of the product is Tukko - Traffic Visualizer.
The Flying Hippos team chose to implement 12 new features based on user interface, security and accessibility, and enhancements to Tukko's existing functionality. When adding each feature, we needed to test all aspects of the product's functionality, performance, security and usability. Ensure that testing activities maximize the identification and resolution of usability issues and performance bottlenecks.
3. Test Items
| Name | Feature Number |
|---|---|
| User Interface and Accessibility | FEA102, FEA106, FEA10110 |
| Data Analysis and Export | FEA201, FEA204 |
| Security and Authentication | FEA401, FEA408 |
| Infrastructure and Performance | FEA505, FEA507, FEA515, FEA516, FEA517 |
4. Features to be Tested
Components and functions to be tested: the scope of what the QA team is responsible for.
5. Features not to be Tested
Components and functions not to be tested: the scope of what lies outside QA responsibility.
| Feature | Why |
|---|---|
| Feature 517 - Maintainable documentation | Other team member are responsible for |
| Feature 516 - Manual testing | Testing method |
6. Approach
Tests will be conducted based on test cases. Team members will work together to test runs with the team leader and test manager. Testers will execute the tests and mark each case as pass/fail. Testers should always leave comments on the actual results and any other relevant details if possible.
a). Unit testing: testing individual product components (program, function, procedure, etc.)
b). Integration testing: the testing process for integrated components and their interaction (components integration, systems integration, etc.)
c). System testing: check the performance of the complete and integrated software as a system.
d). Acceptance testing: check delivery acceptability and product compliance against business requirements.
Testing tools:
7. Item Pass/Fail Criteria
All core functionality of the system should function as expected and as summarized in the individual test cases, and no serious defects should be found. Ninety-five percent of all test cases should pass, and no failed cases are critical to the end user's ability to utilize the application.
8. Suspension Criteria and Resumption Requirements
Specify the criteria that will be used to suspend the testing activities and the requirements for resuming them.
If the system encounters login problems or any basic operation fails, the test should be suspended immediately.
9. Test Deliverables
List all the documents, tools, and other components that will be delivered as part of the testing process.
Before testing: create test plans, test case, and test design specification.
During testing: bug reports, error logs, simulators, test data, etc.
After testing: test report, defect reports.
10. Testing Tasks
Identify the tasks that will be necessary to prepare for and perform the testing activities.
The Tukko project involves several key tasks:
a). Test Plan: Develop a comprehensive test plan.
b). Functional Specification Delivery: Provide detailed functional specifications to the test team.
c). Environment Setup: Ensure that the test environment is ready with the necessary test data and logins.
d). Test Execution: Perform the required tests using various methods.
e). Test Summary Report: Prepare a detailed test summary report highlighting key results and findings.
These steps ensure that the testing process for the Tukko project is systematic and effective.
11. Environmental Needs
Tests are executed on a variety of test environments that may be relevant to ensure coverage of the test session and product compatibility.
12. Responsibilities
| Name | Description | Company/Community |
|---|---|---|
| Joona Tuikkala | Team Leader | Flying Hippos |
| Kosti Katainen | administrator | Flying Hippos |
| Jere Lähteenmäki | Developer / Tester | Flying Hippos |
| Jarno Huusko | Developer / Tester | Flying Hippos |
| Guan Xinyu | Tester / Developer | Flying Hippos |
| Markus Murtonen | Tester / Developer | Flying Hippos |
The testing process is critical for all members of the team. The team leader and test manager are responsible for facilitating the testing program, coordinating tester availability and schedules, and training them as needed. Each tester should be aware of expectations for completion dates and quality levels. Team members should also communicate any risks. Working together to complete testing tasks is the responsibility of the Flying Hippos.
13. Staffing and Training Needs
Testing is done by a full-time tester and a part-time tester. Both testers should test each feature. The assigned testers should have basic expertise.
14. Schedule
Testing activities will be adjusted in real time based on the schedule of future factory courses. For a detailed schedule, please refer to the Flying Hippos team's project plan.
15. Risks and Contingencies
We have 12 new features to add and test. Bug fixes and final testing may be delayed if testing frequently has various issues. If testers don't have a global understanding about Tukko, testing may be delayed or not work properly.
16. Approvals
Both the team leader and the test manager must agree on the completion of the testing program and determine when they are ready for the next step.