Master Test Plan
| Document | Master Test Plan |
| Author: | Iiro Peuhkuri |
| Version: | Ver 1.0 |
| Date: | 22.2.2024 |
1. Introduction
This document outlines the testing strategy and comprehensive plan for Tukko Traffic Visualizer. The system under test provides real-time traffic data, average speed measurements, and other traffic-related analytics for selected routes. The scope of testing will cover all the features listed in the development files and ensure compliance with specified requirements.
2. Test Objectives
Our objectives are to verify functionality, reliability, performance, and security of the Tukko Traffic Visualizer. We aim to ensure that the service meets all user expectations and requirements with no critical defects.
3. Test Items
Software items to be tested:
The React-based user interface and its interaction with the Leaflet mapping tools.
The functionality of the custom API that unifies data from the Digitraffic API endpoints.
The long-term data gathering features that allow users to view historical traffic data and anomalies.
The utilization of various plugins such as Geoman and Cluster markers for map visualizations.
The system's adherence to best practices with Typescript and ESLint rulesets.
Containerization of the service using Docker and orchestration with Kubernetes.
Automated testing practices, possibly with tools like Robot Framework, Selenium, etc.
4. Features to be Tested
FEA102 Securely authenticate user account FEA102
FEA103 Save favourite LAM stations to user account FEA103
FEA106 Improve dark mode colors FEA106
FEA110 Enhance color contrast for color blindness FEA110
FEA201 Export data to csv from the database FEA201
FEA204 Count average traffic in chosen area FEA204
FEA304 Localization for Swedish FEA304
FEA305 Localization for Norwegian FEA305
FEA408 Mitigate all GitLab Security dashboard problems FEA408
FEA410 HTTPS Connection FEA410
FFEA505 Configure scalable and resilient infrastructure using containerization FEA505
FEA514 Monitor server loads with a GUI FEA514
FEA515 Automate tests for frontend and backend code FEA515
5. Features not to be tested
These features are not to be tested since there is no need to test these.
FEA516 Manual testing FEA516
FEA517 Maintainable Documentation FEA517
6. Approach
The testing approach will be tiered, beginning with unit tests for individual functions and components, progressing to integration tests where these components interact. System testing will evaluate the full software stack's operations, and acceptance testing will ensure the system meets user and stakeholder requirements. Tools to be used include Jest for unit testing, Cypress for end-to-end testing, and Postman for API testing.
7. Item Pass/Fail Criteria
Pass criteria will include successful execution of all test cases with correct outputs, no critical bugs, and performance within acceptable thresholds. Fail criteria will include any defects that prevent a feature from performing its expected function or degrade user experience significantly.
8. Suspension Criteria and Resumption Requirements
Testing will be suspended if a severe defect that requires system-wide reassessment is found. Resumption will follow the defect's resolution and a subsequent review cycle to confirm the fix's effectiveness.
9. Test Deliverables
Deliverables will include detailed test plans, cases, scripts, automated test suites, bug reports, a test summary report, and a final testing sign-off document.
10. Testing Tasks
Tasks include environment setup, test case development, test execution, bug tracking, test results analysis, and reporting.
11. Environmental Needs
A mirrored production environment with corresponding hardware, software, and network configurations is required. Accessibility to version control and CI/CD pipelines for software deployment is also necessary.
12. Responsibilities
As the sole individual responsible for testing, I will manage the entire testing lifecycle. This includes strategizing, creating test plans, executing test cases, documenting defects, and ensuring that testing is aligned with the project timeline.
13. Staffing and Training Needs
Given my role as a student and novice tester with limited previous experience and time, the training needs are focused and practical. I will prioritize learning essential testing techniques and tools that are immediately relevant to the project.
14. Schedule
A testing schedule will be aligned with the development sprints, with each sprint ending with a testing phase. Key milestones will include major feature completions and integration points.
15. Risks and Contingencies
Risks include delays in development affecting testing, discovery of significant defects requiring extensive rework, and resource unavailability. Contingency plans will involve resource reallocation, schedule adjustments, and scope redefinition.
16. Approvals
The Master test plan requires approval from the Project Manager and Stakeholder Representative before the commencement of testing activities.