Master Test Plan
| Document | Master Test Plan |
| Author: | Ville-Veikko Vähäaho |
| Version: | Ver 1.0 |
| Date: | 23.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:
Master Test Plan
1. Introduction
This Master Test Plan is for Project Propp, where we are adding features to the already existing application, Tukko - Traffic Visualizer. The testing will be conducted by the team's tester, Ville-Veikko Vähäaho, and Team Leader Jere Myllylä. Documentation will be managed using GitLab and the Open Project Framework.
2. Test Objectives
The team's objective is to test Tukko and its new features that are being added.
We will test the service on the following criteria:
- Functionality: Validate that the new features work according to the given requirements.
- Accessibility: Evaluate the software's user-friendliness and overall user experience.
- Security: Identify and mitigate potential security vulnerabilities.
- Performance: Assess the system's performance under different conditions.
3. Test Items
The test items include all the new features listed in the below Section #4. Additionally, we will be testing the functionality of the map, user interface, and APIs.
4. Features to be Tested
| FEA Number | Feature | Functionalities | Functional Requirement / User Story |
|---|---|---|---|
| FEA101 | Compare different LAM stations side by side | Ability to compare two different LAM stations' data side by side | FUNCTIONAL-REQ-001 |
| FEA106 | Improve dark mode colors | Updated dark mode colors to be more user friendly and easier to look at | FUNCTIONAL-REQ-002 |
| FEA109 | Search location by name | A text input search bar to easily find a specific location from the map | FUNCTIONAL-REQ-003 |
| FEA110 | Enhance color contrast for color blindness | An option to turn color blindness mode on/off | FUNCTIONAL-REQ-004 |
| FEA111 | Provide road condition reports | Markers on roads to indicate abnormal road conditions | FUNCTIONAL-REQ-005 |
| FEA112 | Change branding to team and JAMK brand | Updated branding to match the team and JAMK | FUNCTIONAL-REQ-006 |
| FEA201 | Export data to csv from the database | Ability to export recent traffic data in .csv format | FUNCTIONAL-REQ-007 |
| FEA203 | Export history data from specific dates | Ability to export traffic data from a specific time frame | FUNCTIONAL-REQ-008 |
| FEA302 | Traffic situation in Sweden | Expansion to the product to show current traffic data in Sweden | FUNCTIONAL-REQ-008 |
| FEA304 | Localization for Swedish | Ability to switch product language to Swedish | FUNCTIONAL-REQ-009 |
| FEA516 | Manual Testing | Manual testing will include Unit, Integration, Monkey and System testing | FUNCTIONAL-REQ-012 |
5. Features not to be Tested
| FEA Number | Feature | Functionalities | Functional Requirement / User Story |
|---|---|---|---|
| FEA404 | Enforce secure coding practices | All code will follow security guidelines | FUNCTIONAL-REQ-011 |
| FEA403 | Regularly scan for known security vulnerabilities | Scans performed by team security at regular intervals. Scans performed with specified tools and strategies | FUNCTIONAL-REQ-010 |
6. Approach
The test team will conduct the following types of testing:
- Unit Testing
- Software Testing
- Integration Testing
- Monkey Testing
- End-to-End Testing
- Acceptance testing
Sanity testing will be performed after minor changes. All testing will be carried out manually unless stated otherwise or if there is a need to automate. For automated testing, we will use the Robot Framework.
7. Item Pass/Fail Criteria
A feature or item will pass the test case when it successfully meets all the requirements outlined in the planned test case. If the feature does not meet all the specified criteria, it will be considered a failure in the test.
8. Suspension Criteria and Resumption Requirements
Testing may be suspended under the following conditions:
- Critical System Errors: If critical errors arise within the system that pose a significant risk, testing will be temporarily suspended.
- Resource Constraints: In cases where there are resource constraints, such as unavailability of required systems, testing may be paused.
- Critical Security Concerns: If there are critical security concerns, testing may be halted to address these issues.
Testing will resume once the critical errors are fixed, resources become available, or security concerns have been addressed and resolved.
9. Test Deliverables
Documents related to testing, including the Master Test Plan, Test Cases, and Test Reports, can be accessed and managed under the test management section in the Open Project Framework.
10. Testing Tasks
Planning for the tests is a crucial part of the testing process. Testers must have a clear understanding of the expected behavior of each feature and plan the tests accordingly. It is essential to document and record the tests, ensuring that all errors and bugs are reported accurately. This comprehensive approach to planning and documentation contributes to a more effective and organized testing process.
11. Environmental Needs
Our testing environment will be conducted within our CSC virtual machines. For browser testing, Google Chrome will be the primary browser used. However, the service will also undergo testing with other browsers, such as Firefox, Edge, etc., to ensure compatibility across different platforms and enhance overall browser support.
12. Responsibilities
Tester Ville-Veikko Vähäaho will take responsibility for testing and will conduct the majority of the tests. Team Leader Jere Myllylä will also be involved in conducting tests. Security expert Mikko Partenen will contribute to security testing, ensuring a comprehensive evaluation of the system's security aspects.
13. Staffing and Training Needs
The test team needs to familiarize themselves with the test documentation, understand how to conduct test cases effectively, and learn the process of building a Robot Framework if it is required. This knowledge and skill development are essential to ensure a smooth and efficient testing process.
14. Schedule
The majority of the testing should be completed before the Demo day. The tests will be conducted according to the schedule outlined in the project plan. This adherence to the schedule will help ensure that the testing phase aligns with the overall project timeline.
15. Risks and Contingencies
Risks associated with the testing phase include:
- Tester Availability: There is a risk of the tester getting sick, which could impact the testing schedule.
- Technical Problems: Technical issues, such as software or hardware failures, may disrupt the testing process.
- Power Outages: Unplanned power outages could potentially affect the testing environment.
- Unforeseen Problems: There is a possibility of encountering unforeseen issues that were not accounted for in the testing plan.
Mitigation strategies should be in place to address these risks, such as having a backup tester, implementing robust technical support, ensuring power backup solutions, and maintaining flexibility to adapt to unforeseen challenges.
16. Approvals
The approval of test cases should be obtained from at least one team member, typically Team Leader Jere Myllylä. This ensures that the test cases have undergone a thorough review and validation before being executed, contributing to the overall quality and reliability of the testing process.